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

function literal used as a statement #1565

Closed
scabug opened this issue Dec 4, 2008 · 6 comments
Closed

function literal used as a statement #1565

scabug opened this issue Dec 4, 2008 · 6 comments
Assignees

Comments

@scabug
Copy link

scabug commented Dec 4, 2008

scala> object X { 0;  (a : Int, b : Int) => println(List(a, b))   }
<console>:1: error: ';' expected but '=>' found.
       object X { 0;  (a : Int, b : Int) => println(List(a, b))   }

Shouldn't this situation be allowed? A function literal is an expression, and an expression is usable as a statement. I tried to make Issue 1564, but I ran into this issue.

On a related note, the following output is weird:

scala> def x() = { 0; (a : Int, b : Int) => println(List(a, b)) ; 0  }
x: ()(Int, Int) => Int

Shouldn't x be a function from ()=>Int ?

@scabug
Copy link
Author

scabug commented Dec 4, 2008

Imported From: https://issues.scala-lang.org/browse/SI-1565?orig=1
Reporter: @lexspoon

@scabug
Copy link
Author

scabug commented Dec 4, 2008

Geoffrey Alan Washburn (washburn) said:

scala> def x() = { 0; (a : Int, b : Int) => println(List(a, b)) ; 0  }
x: ()(Int, Int) => Int

Shouldn't x be a function from ()=>Int ?

No, for two reasons. (1) x is a method. Method types are printed as (argtypes)restype. (2) Anonymous functions are not restricted to having expressions as their bodies, so the parser is interpreting the body of the anonymous function as extending to the right brace. Therefore, the method is returning an anonymous function returning 0, not 0.

@scabug
Copy link
Author

scabug commented Dec 4, 2008

@lexspoon said:
The interpreter treats it as a function, for whatever reason. Anyway, oddity aside, the more important issue is the first problem. Shouldn't any expression be usable as a top-level statement? It's livable if that isn't true, but the interpreter needs patching if so. Also, it's just nice being able to tell people that any expression can be used as a statement.

@scabug
Copy link
Author

scabug commented Dec 4, 2008

Geoffrey Alan Washburn (washburn) said:
Uh, in what way is it being treated as a function? It looks like it is being treated like a method to me.

Yes, arbitrary expressions should ideally be usable as statements. But as I pointed out in #1564, the problem is not at all related to how the interpreter is implemented. The problem is entirely within the parser.

@scabug
Copy link
Author

scabug commented Dec 5, 2008

@lexspoon said:
You're right, it's treated as a method. Excellent. I mis-parsed the type as a function with two parameter lists.

I'll comment on #1654 on #1564.

@scabug
Copy link
Author

scabug commented Feb 18, 2009

@paulp said:
Fixed in r17144. I will comment with some detail in #1564.

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