Vals shadow type aliases

[mpilquist]

› ./amm
Loading...
Welcome to the Ammonite Repl 0.4.5
(Scala version 2.11.7 Java 1.8.0_25)
@ type Foo = Int
defined type Foo
@ val Foo = 1
Foo: Int = 1
@ 1: Foo
Compilation Failed
Main.scala:52: not found: type Foo
1: Foo
   ^
@

[Blaisorblade]

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

[Blaisorblade]

First hypothesis: Ammonite and Scala REPL differ in how they wrap naked expressions to turn them into compilation units.
I'd compare Evaluator.wrapCode in repl/src/main/scala/ammonite/repl/interp/Evaluator.scala with the equivalent in the Scala REPL; but Preprocess might also be relevant.

Alternatively, I'd use -Xprint:typer to debug what happens — but that's currently only possible on the official REPL, not on Ammonite.

[Blaisorblade]

Amazing. With -Xprint:parser, I discovered that the official REPL adds import $line4.$read.$iw.$iw.Foo; or import $line3.$read.$iw.$iw.Foo; to import one or the other Foo in later statements that use it, taking the namespace of the identifier into account.

I'm scar(r)ed O_O.

[lihaoyi]

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 previousImports map instead of just one - but Scala's import behavior has always surprised me

[paulp]

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

[paulp]

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.

[lihaoyi]

I don't need to fix it forever, just enough to get my second term

[lihaoyi]

Hopefully it won't get shadowed by someone else's second type though

[som-snytt]

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 :imports command that gave you some control, quarantining symbols for templating purposes. Maybe the other model is control over history: people want to selectively forget results (for purposes of garbage collection), which could also be handy for cleaning up namespaces.

[paulp]

Doesn't appear to be fixed at all. Here's a test case, and what it does in the scala repl.

package p1 {
  class Order
}

package p2 {
  object Order {
    def apply(x: p1.Order): Unit = println("ok!")
  }
}
// Welcome to Scala version 2.11.7 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_72).
// Type in expressions to have them evaluated.
// Type :help for more information.
//
// scala> import p1._, p2._ ; Order(new Order)
// ok!

Here's ammonite 0.5.3 failing.

@ import p2._, p1._
import p2._, p1._
@ Order(new Order)
Main.scala:44: not found: value Order
Order(new Order)
^
Compilation Failed
@ p2.Order
res1: p2.Order.type = p2.Order$@49a94903
@ new p1.Order
res2: Order = p1.Order@4ceb815f
@

[lihaoyi]

What I've found so far:

• I need to filter .allImportedSymbols based on sym.exists. Why am I getting non-existent symbols? GOK
• The logic around deciding the name of an import-selector-name is wrong. .isTypeName is never true. May need to dig into the symbols and types and figure that out myself