- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Fixing shadowed variable names
Mon, 2011-06-06, 23:46
Hi,
As observed before, there might be trees coming at late phase that have confusing names. Let's look at case class'es equals method again:
[[syntax trees at end of cleanup]]// Scala source: A.scala package <empty> { case class A extends java.lang.Object with ScalaObject with Product with Serializable {//not interesting stuff removed
override def equals(x$1: java.lang.Object): Boolean = A.this.eq(x$1).||({ //some code removed for brevity val x$1: Int = temp3; if (A.this.gd1$1(x$1)) body%01(x$1){ x$1.$asInstanceOf[A]().canEqual(A.this) //this line looks suspicious }
Here we have a case where x$1 inside of body%01 LabelDef refers to x$1 defined as parameter of equals method. The problem is that we have another declaration of x$1 that shadows the parameter. If we were to rely on trees' names instead of symbols attached to them we would be in trouble.
Actually, that's the trouble I face in my jribble backend (part of scalagwt project) where I do rely on names of ValDefs when trying to emit code (in a form similar to what you see when you print trees as above) for accessing them. One could imagine that this kind of situations could be detected and fixed by introducing local ValDefs that resolve the conflict:
//some code removed for brevity //unshadowed val is being introduced right before ValDef that shadows val from outer scope that we will want to access later on before leave a scope of shadowing variable val unshadowed$1: java.lang.Object = x$1 val x$1: Int = temp3; if (A.this.gd1$1(x$1)) body%01(x$1){ unshadowed$1.$asInstanceOf[A]().canEqual(A.this) //this line looks suspicious }
I'm not sure if doing this kind of tree transformation is easy to implement in a way that covers any possible situation like this. I was wondering if anyone from Scala team was dealing with this kind of a problem in a past and can share some code or thoughts if my approach looks sensible.
Also, some tips how to implement this (maybe by reusing some existing functionality in nsc that I'm not aware of) would be great.
--
Grzegorz Kossakowski
As observed before, there might be trees coming at late phase that have confusing names. Let's look at case class'es equals method again:
[[syntax trees at end of cleanup]]// Scala source: A.scala package <empty> { case class A extends java.lang.Object with ScalaObject with Product with Serializable {//not interesting stuff removed
override def equals(x$1: java.lang.Object): Boolean = A.this.eq(x$1).||({ //some code removed for brevity val x$1: Int = temp3; if (A.this.gd1$1(x$1)) body%01(x$1){ x$1.$asInstanceOf[A]().canEqual(A.this) //this line looks suspicious }
Here we have a case where x$1 inside of body%01 LabelDef refers to x$1 defined as parameter of equals method. The problem is that we have another declaration of x$1 that shadows the parameter. If we were to rely on trees' names instead of symbols attached to them we would be in trouble.
Actually, that's the trouble I face in my jribble backend (part of scalagwt project) where I do rely on names of ValDefs when trying to emit code (in a form similar to what you see when you print trees as above) for accessing them. One could imagine that this kind of situations could be detected and fixed by introducing local ValDefs that resolve the conflict:
//some code removed for brevity //unshadowed val is being introduced right before ValDef that shadows val from outer scope that we will want to access later on before leave a scope of shadowing variable val unshadowed$1: java.lang.Object = x$1 val x$1: Int = temp3; if (A.this.gd1$1(x$1)) body%01(x$1){ unshadowed$1.$asInstanceOf[A]().canEqual(A.this) //this line looks suspicious }
I'm not sure if doing this kind of tree transformation is easy to implement in a way that covers any possible situation like this. I was wondering if anyone from Scala team was dealing with this kind of a problem in a past and can share some code or thoughts if my approach looks sensible.
Also, some tips how to implement this (maybe by reusing some existing functionality in nsc that I'm not aware of) would be great.
--
Grzegorz Kossakowski
Fri, 2011-06-10, 09:57
#2
Re: Fixing shadowed variable names
Hi,
I do not have an answer for the real issue. But maybe I can provide
with a solution to your direct problem. I have also experienced the
same problem for a back-end I am developing, and I also use variable
names.
My solution for this problem is, for *local* values only, to use the -
uniqid when deriving the name of the local. e.g. if the value is name
x, and its unique id is 432, then its name in the back-end will be
x~432. Depending on the valid identifier names in your back-end,
you'll have to adapt. You can obtain the unique id of a sym:Symbol
with sym.id
Hope it helps,
Sébastien
On 10 juin, 00:18, Grzegorz Kossakowski
wrote:
> 2011/6/7 Grzegorz Kossakowski
>
> I'm not sure if doing this kind of tree transformation is easy to implement
>
> > in a way that covers any possible situation like this. I was wondering if
> > anyone from Scala team was dealing with this kind of a problem in a past and
> > can share some code or thoughts if my approach looks sensible.
>
> > Also, some tips how to implement this (maybe by reusing some existing
> > functionality in nsc that I'm not aware of) would be great.
>
> Hi,
>
> Since Scala Days are over and everyone returned back to their homes I was
> wondering if someone could give my question a try?
>
> --
> Grzegorz Kossakowski
Fri, 2011-06-10, 14:27
#3
Re: Re: Fixing shadowed variable names
2011/6/10 Sébastien Doeraene aka sjrd <sjrdoeraene@gmail.com>
Hi Sebastien,
Thanks for your answer!
Indeed, your solution looks very promising due to fact that it doesn't require too much effort to introduce. I didn't know that compiler generates unique ids even if -uniqueid option is turned off. However, I checked in Symbols.scala and indeed unique ids are always computed.
Still, I would wish that earlier compiler phases were doing better job at coming up with unique names so hacks like that wouldn't be needed. One big disadvantage is that output of my backend will be very unstable (names will be changed all the time) so it'll make debugging much, much harder.
--
Grzegorz Kossakowski
Hi,
I do not have an answer for the real issue. But maybe I can provide
with a solution to your direct problem. I have also experienced the
same problem for a back-end I am developing, and I also use variable
names.
My solution for this problem is, for *local* values only, to use the -
uniqid when deriving the name of the local. e.g. if the value is name
x, and its unique id is 432, then its name in the back-end will be
x~432. Depending on the valid identifier names in your back-end,
you'll have to adapt. You can obtain the unique id of a sym:Symbol
with sym.id
Hi Sebastien,
Thanks for your answer!
Indeed, your solution looks very promising due to fact that it doesn't require too much effort to introduce. I didn't know that compiler generates unique ids even if -uniqueid option is turned off. However, I checked in Symbols.scala and indeed unique ids are always computed.
Still, I would wish that earlier compiler phases were doing better job at coming up with unique names so hacks like that wouldn't be needed. One big disadvantage is that output of my backend will be very unstable (names will be changed all the time) so it'll make debugging much, much harder.
--
Grzegorz Kossakowski
Fri, 2011-06-10, 15:17
#4
Re: Re: Fixing shadowed variable names
On 6/10/11 6:25 AM, Grzegorz Kossakowski wrote:
> Still, I would wish that earlier compiler phases were doing better job
> at coming up with unique names so hacks like that wouldn't be needed.
Pull requests welcome.
Fri, 2011-06-10, 15:27
#5
Re: Re: Fixing shadowed variable names
2011/6/10 Paul Phillips <paulp@improving.org>
Since this is quite a big pain for me I could give this a try in three weeks once hacking nsc becomes my full time job for summer. I'd love to know how hard this could be to fix. I'm wondering if there's any deep reason for such design decision to not choose unique names in first place?
--
Grzegorz Kossakowski
On 6/10/11 6:25 AM, Grzegorz Kossakowski wrote:
> Still, I would wish that earlier compiler phases were doing better job
> at coming up with unique names so hacks like that wouldn't be needed.
Pull requests welcome.
Since this is quite a big pain for me I could give this a try in three weeks once hacking nsc becomes my full time job for summer. I'd love to know how hard this could be to fix. I'm wondering if there's any deep reason for such design decision to not choose unique names in first place?
--
Grzegorz Kossakowski
Fri, 2011-06-10, 16:27
#6
Re: Re: Fixing shadowed variable names
On 6/10/11 7:13 AM, Grzegorz Kossakowski wrote:
> Since this is quite a big pain for me I could give this a try in three
> weeks once hacking nsc becomes my full time job for summer. I'd love to
> know how hard this could be to fix. I'm wondering if there's any deep
> reason for such design decision to not choose unique names in first place?
Unless someone knows otherwise: it's not a design decision, it's just
what someone (probably me) bulldozed into an apparently working state
with the knowledge possessed at the time.
Sat, 2011-06-11, 10:17
#7
Re: Fixing shadowed variable names
On 10 juin, 16:13, Grzegorz Kossakowski
wrote:
> Since this is quite a big pain for me I could give this a try in three weeks
> once hacking nsc becomes my full time job for summer. I'd love to know how
> hard this could be to fix.
I could also give it a try in the summer :-)
> Unless someone knows otherwise: it's not a design decision, it's just
> what someone (probably me) bulldozed into an apparently working state
> with the knowledge possessed at the time.
So if we can find the place where they are introduced and fix this at
the source, that's fine with you?
Hi,
Since Scala Days are over and everyone returned back to their homes I was wondering if someone could give my question a try?
--
Grzegorz Kossakowski