Very slow compilation with SAM types with multiple parameter lists

[smarter]

Foo here should probably not be treated as a SAM type if we want to be sane:

trait Foo {
  def app(x: Object)(y: Object): Object
}

object O {
  def main(args: Array[String]): Unit = {
    val z: Foo = x => ???
  }
}

Currently it takes a long time to produce an error message, it seems to spend most of its time in implicit search before giving up:

[error] try/closmulti.scala:7: error: type mismatch:
[error]  found   : Nothing
[error]  required: (y: Object)Object
[error]     val z: Foo = x => ???
[error]                       ^
[error] one error found

[DarkDimius]

Why shouldn't Foo be treated as a SAM type? It's a perfectly valid SAM-type after erasure.
Multiple argument lists have important use cases for dependently typed arguments:

def apply(a: X)(b: a.T): a.Y    // allowed 
// def apply(a: X, b: a.T): a.Y // disallowed

[smarter]

Treating something as a SAM type is only useful so that you can write "x => ..." instead of "new Foo { ... }", how can you write a closure with multiple parameter lists?

[DarkDimius]

x  => y => if(rand.nextBool) x else y

[odersky]

No, that will create two closures.

On Mon, Apr 27, 2015 at 8:52 PM, Dmitry Petrashko notifications@github.com
wrote:

x: Int => y: Int => x + y

—
Reply to this email directly or view it on GitHub
#490 (comment).

Martin Odersky
EPFL

[DarkDimius]

Currently - yes, but they could be easily flattened.

[DarkDimius]

result of O.scala after erasure:
...
      def $anonfun(x: Object): Object = {
        def $anonfun(y: Object): Object = if rand.nextBool then x else y
        closure($anonfun)
      }
      closure($anonfun:Foo)
...

At this moment the flattening can be implemented as a simple mini-phase, that rewrites outer $anonfun to take two parameters.

[smarter]

Closing since the slowness to produce the error seems to have disappeared. It's also unlikely we'll support SAMs with multiple parameter lists so I won't open a separate issue for that.