Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem parsing anonymous functions with 2+ params #1564

Closed
scabug opened this issue Dec 3, 2008 · 8 comments
Closed

Problem parsing anonymous functions with 2+ params #1564

scabug opened this issue Dec 3, 2008 · 8 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Dec 3, 2008

This works fine with zero or single parameters

scala> 8
res11: Int = 8

scala> (a : Int) => println(List(a)) 
res12: (Int) => Unit = <function>
scala> res12(res11)
List(8)

But when trying with 2+ parameters it failed:

scala> (a : Int, b : Int) => println(List(a, b))
<console>:1: error: not a legal formal parameter
       (a : Int, b : Int) => println(List(a, b))
@scabug
Copy link
Author

scabug commented Dec 3, 2008

Imported From: https://issues.scala-lang.org/browse/SI-1564?orig=1
Reporter: @thebugslayer
Attachments:

@scabug
Copy link
Author

scabug commented Dec 3, 2008

Geoffrey Alan Washburn (washburn) said:
As noted in the thread on the mailing list this has nothing to to with the interpreter. Consider

class Foo {
  (a : Int, b : Int) => println(List(a, b))
}

which fails in the compiler. The problem is how template statements are parsed.

@scabug
Copy link
Author

scabug commented Dec 4, 2008

@lexspoon said:
The interpreter should handle this. The given expression is not only valid, but something that users are likely to try. If nothing else, the existing special case for individual expressions can be expanded so as to include this use case.

A partial fix is in the attachment interpAddsSemi-r16705.patch. All it does is insert a semicolon before the user code, thus avoiding any attempt by the parser to treat the user code as a this alias. This patch does not work due to issue #1565, but if #1565 can be fixed it should work. If #1565 needs to stay the way it is for some reason, then there are alternate strategies available for 1564.

@scabug
Copy link
Author

scabug commented Dec 4, 2008

Geoffrey Alan Washburn (washburn) said:
We should not be patching the interpreter for this bug. This has nothing to do with how the interpreter is implemented and is entirely a bug within the parser. The parser should be fixed instead of adding pointless workarounds in the interpreter.

@scabug
Copy link
Author

scabug commented Dec 5, 2008

@lexspoon said:
I agree there is a parser problem, but as I described above there is also a general issue for the interpreter. Currently, the interpreter asks the parser to parse a whole template statement sequence, including a possible this alias. At the very least this is a fragile arrangement, because no top-level code entered at the interpreter prompt will be a this alias. For things to work correctly, we are relying on the parser trying but always failing to parse a this alias.

Here's a problem related to the initial one given above:

  scala> a : Int => println("hello")

Without a patch, the interpreter will attempt to parse something analogous to this:

  object wrapper { a : Int => println("hello") }

This will parse in a different way than intended. At the least that looks fragile. It should make the interpreter more robust if it didn't even try to parse such a construction, which is why I suggested putting in a semicolon. If there is a better way to eliminate the possibility of a this alias than a semicolon, that would also be great.

@scabug
Copy link
Author

scabug commented Dec 6, 2008

Geoffrey Alan Washburn (washburn) said:
Ah, I think understand the problem now. It should be possible to correct the parser to better disambiguate anonymous functions and self-types, but I'll need to talk to someone who knows more about the parser to see just what the best solution would be.

@scabug
Copy link
Author

scabug commented Feb 18, 2009

@paulp said:
I have just committed r17144 and closed #1565. The bug originally reported in this ticket works fine now:

scala> (a : Int, b : Int) => println(List(a, b))
res0: (Int, Int) => Unit = <function>

scala> res0(5, 10)
List(5, 10)

However lex's specific example is thorny:

a : Int => println("hello")

That is, I think the specific case of an unparenthesized one-argument function may be best dealt with by special casing the interpreter, because I'm pretty sure disambiguating it in the parser is impossible.

// is that a function or a self-type? 
scala> class Foo
scala> class Bar extends Foo { self: Bar => println("hi") }

I'll look at this some more but I think the lion's share of the available improvement is in the patch for 1565.

@scabug
Copy link
Author

scabug commented Feb 27, 2009

@paulp said:
Not having come up with any brilliant insights as to disambiguate these cases and skeptical that it warrants special casing the interpreter, I am closing this as fixed. If any other interested parties disagree please feel free to reopen this ticket and share your feelings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants