DartVM: Function expression invocation fails if function has a name

[DartBot]

This issue was originally filed by syab...@gmail.com

---

What steps will reproduce the problem? Run the following test: main() {   f(p1, p2) {print(p1);}("a", "b"); }

What is the expected output? What do you see instead? Expected output: string "a". Actual: compile error

What version of the product are you using? On what operating system? DartVM, r3482; OS: Ubuntu 10.04

Please provide any additional information below. (p1, p2) {print(p1);}("a", "b"); compiles and executes without errors. f(p1, p2) {print(p1);}("a"); also compiles and executes without errors, and output is an empty string.

[dgrove]

Added Area-VM, Triaged labels.

[DartBot]

This comment was originally written by @mhausner

---

Set owner to @mhausner.

[kasperl]

Hmm. I think we should think about this some more. I don't think it was ever the intent to treat a named function expression at a statement position as anything but a nested function. So I would argue that

  f(p1, p2){print(p1);}("a", "b");

at a statement position should lead to a compilation error because we don't have a comma expression.

[kasperl]

See the corresponding frog bug in issue #1522.

[DartBot]

This comment was originally written by @mhausner

---

I'm holding off with my change until this is clarified, hopefully soon.

[iposva-google]

Added Accepted label.

[DartBot]

This comment was originally written by @mhausner

---

Here's another version of the same problem that doesn't even involve calling the function literal. One of the co19 tests uses function literals as operands of a binary operator. That is of course nonsensical, but legal dart code at the moment.

try {void f() {return null;} & void g(int x) => 7;} catch(var e) {}

Should the above parse correctly and apply the & operator to the literals, or should this be a syntax error because the function literal f is interpreted as a function declaration statement?

I would really like clarification on this before I continue working on the issue. I still have a change outstanding that I'm holding until this is sorted out in the spec.

---

cc @gbracha. cc @kasperl.

[gbracha]

I really don't see this as a problem in itself. This is an expression, and unless we change the syntax substantially (for example, disallow the use of named function literals) it should just execute (in the 2nd case, a noSuchMethod would occur).

That said, we are currently discussing the related issue of whether the name f would be in scope in this case, and solutions may involve changing the syntax. So stay tuned.

[kasperl]

I do see this as a problem. The f function is in a statement position so it leads to confusions. Gilad and I are exploring various options in this area and will keep you posted.

[DartBot]

This comment was originally written by @mhausner

---

Any progress in putting this into the spec?

[DartBot]

This comment was originally written by @mhausner

---

It looks like we have an agreement on what the spec should be, so this can be fixed for M1.

---

Added this to the M1 milestone.

[iposva-google]

Removed this from the M1 milestone. Added this to the M2 milestone.

[DartBot]

This comment was originally written by @mhausner

---

Working on this now. Biggest part is in adapting the libraries and tests.

---

Added Started label.

[iposva-google]

Removed this from the M2 milestone. Added this to the M3 milestone.

[DartBot]

This comment was originally written by @mhausner

---

Just eliminated legacy function literals in the VM compiler. This issue is closed.

---

Added Fixed label.