Vals shadow type aliases #199
Comments
And the other way around. Continuing the transcript: @ type Foo = Int
defined type Foo
@ val Foo = 1
Foo: Int = 1
@ 1: Foo
Compilation Failed
Main.scala:36: not found: type Foo
1: Foo
^
@ type Foo = Int
defined type Foo
@ Foo
Compilation Failed
Main.scala:36: not found: value Foo
Foo
^
@ 1: Foo
res3: Foo = 1 |
First hypothesis: Ammonite and Scala REPL differ in how they wrap naked expressions to turn them into compilation units. Alternatively, I'd use |
Amazing. With -Xprint:parser, I discovered that the official REPL adds I'm scar(r)ed O_O. |
lol the REPL is scary isn't it. I suspect this won't be too hard to fix - just keep track of two namespaces in the |
Nothing quite so terrifying as working code I guess. In my case the shadowing happens like import pkg1._ // this has trait Order, no terms
import pkg2._ // this has object Order, no types
new Order // not found: type Order |
It's pretty incredible that I can articulate what is the challenge and then you can swoop in a year and a half later and declare it "fixed" while falling prey to exactly the problem I described. |
I don't need to fix it forever, just enough to get my second term |
Hopefully it won't get shadowed by someone else's second type though |
On surprising behavior of imports generally, I almost commented on paulp's recent ticket, then realized I could explain one behavior but not the other, and then I had other stuff to do that day. https://issues.scala-lang.org/browse/SI-9552 If you allow mucking with the template, with user-mucked wrapping of the expression, then automation feels even more challenging. A while ago I had a PR with an |
Doesn't appear to be fixed at all. Here's a test case, and what it does in the scala repl.
Here's ammonite 0.5.3 failing.
|
What I've found so far:
|
Yes all imported names are created as TermNames before it is known what they actually are. |
AFAICT it's already an improvement but if you find other things which are easily fixed in the interim then might as well fix all those before publishing 0.5.4 |
I can give you some high level advice: work in terms of imported and defined symbols, not names. A reference to a name in some namespace then resolves to the most recently imported symbol which has that name. I would also use something like ChainMap to preserve the history of each name in the repl. That branch is a work in progress from when I was toying with forking ammonite. It's intended to provide a better foundation for solving the problem in this ticket. Feel free to make use of any of it. |
Ok thanks! Perhaps in a future diff I'll make use of that. For now I'll publish what I have first since it fixes obvious (easy to hit!) brokenness soonish and then maybe spend time ratholing in scala-compiler-details later... |
@paulp Thanks a lot! I'll take a look when I get home from removing dead snakes at work today |
As an orthogonal issue, my previous comment meant to say, |
FSR, my office snakes are live. Like Indiana Jones, "I hate snakes," etc. I don't actually hate snakes, speaking metaphorically. I think we need a photo of Miles's dog as a type astronaut. |
The text was updated successfully, but these errors were encountered: