parser incorrectly reports self type error for lambda in template

[retronym]

class Test {
  (x: Int) => x
}

sandbox/test.scala:2: error: not a legal self type clause (class dotty.tools.dotc.ast.untpd$Parens)
  (x: Int) => x
  ^
sandbox/test.scala:2: error: package x is not a value
  (x: Int) => x
   ^
sandbox/test.scala:2: error: package x is not a value
  (x: Int) => x
              ^
three errors found

[odersky]

I would argue this is what we want. A class containing a lambda in statement position makes no sense. So, it's more likely the user wanted to write a self type here and got the syntax wrong.

It also means we can clean up a particularly murky corner of scalac's parser.

[retronym]

Good point. But...

This would mean that a code generator and will need to insert a dummy expression before wrapping an arbitrary list of expressions in a template.

[odersky]

Yes, but is this a problem for non-sensical expressions? Why generate such code anyway?

[retronym]

For instance, The REPL wraps user written code in a template so they can be typechecked.

[retronym]

e.g.:

⚡ scala
Welcome to Scala 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_102).
Type in expressions for evaluation. Or try :help.

scala> :silent

scala> () => 42

[retronym]

You can argue that () => 42 is non-sensical, but if we want to provide such guidance it can't be through the "illegal self type error" in generated code 😄

[odersky]

Good point...

On Sun, Jul 31, 2016 at 7:24 PM, Jason Zaugg notifications@github.com
wrote:

You can argue that () => 42 is non-sensical, but if we want to provide
such guidance it can't be through the "illegal self type error" in
generated code 😄

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1424 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwlVjbZof_2I9d6Qv5fBwGF_v-H4Nb8ks5qbNpQgaJpZM4JXkta
.

Prof. Martin Odersky
LAMP/IC, EPFL

[odersky]

Except for:

scala> x => println(1)
<console>:1: error: ';' expected but '=>' found.
x => println(1)
  ^

So it seems the REPL has to special case closures in any case.

[retronym]

Nice find!

However, that looks like a general parser bug within templates:

scala> class C { (); x => 42; () }
<console>:1: error: ';' expected but '=>' found.
class C { (); x => 42; () }
                ^
      ^

[retronym]

Oh, templates only allow Expr1, not Expr:

Expr       ::= (Bindings | [`implicit'] Id | `_')  `=>' Expr
     *               | Expr1

[odersky]

I see. So closures have to be put in parentheses by the REPL anyway.