github at esdiscuss.org (2013-07-12T02:24:50.331Z)
This approach requires a restriction: [no LineTerminator here] between the `)` and the `{`:
```
js> function f(a,b,c){return a*b+c}
js> var x=2,y=3,z=4,w
js> f(x,y,z) {
typein:3: SyntaxError: missing ; before statement:
typein:3: f(x,y,z) {
typein:3: .........^
js> eval("w=f(x,y,z)\n{print(w)}")
10
```
(That last `10` came from `print(w)` of course; the completion value of the `eval` was undefined.)
Leaving out the `f` in the "definition" doesn't help, since `(a,b,c)` is a comma expression. The requirement is no `LineTerminator` between the `)` and the `{`.
We went around a nearby block recently, in considering `{(a,b)...}` for block lambdas. Everyone I remember initially favoring this syntax came around to oppose it because the opportunity for confusion due to parenthesized expression statements already mixing with curly-braced block statements was too great.
Perhaps this case is different enough. But is it? Modified Prototype 1.6:
```javascript
inGroupsOf(number, fillWith) {
fillWith = Object.isUndefined(fillWith) ? null : fillWith;
return this.eachSlice(number, (slice) {
while(slice.length < number) slice.push(fillWith);
return slice;
});
},
inject(memo, iterator, context) {
iterator = iterator.bind(context);
this.each((value, index) {
memo = iterator(memo, value, index);
});
return memo;
},
invoke(method) {
var args = $A(arguments).slice(1);
return this.map((value) {
return value[method].apply(value, args);
});
},
```
I've obviously also used method definition shorthand by changing any `function (` occurrences in the original prototype code to just `(`.
Without a leading keyword, it's harder to find the functions. Not impossible, not saying this is a deal breaker. But it is harder.
This approach requires a restriction: [no LineTerminator here] between the ) and the {: js> function f(a,b,c){return a*b+c} js> var x=2,y=3,z=4,w js> f(x,y,z) { typein:3: SyntaxError: missing ; before statement: typein:3: f(x,y,z) { typein:3: .........^ js> eval("w=f(x,y,z)\n{print(w)}") 10 (That last "10" came from print(w) of course; the completion value of the eval was undefined.) Leaving out the f in the "definition" doesn't help, since (a,b,c) is a comma expression. The requirement is no LineTerminator between the ) and the {. We went around a nearby block recently, in considering {(a,b)...} for block lambdas. Everyone I remember initially favoring this syntax came around to oppose it because the opportunity for confusion due to parenthesized expression statements already mixing with curly-braced block statements was too great. Perhaps this case is different enough. But is it? Modified Prototype 1.6: inGroupsOf(number, fillWith) { fillWith = Object.isUndefined(fillWith) ? null : fillWith; return this.eachSlice(number, (slice) { while(slice.length < number) slice.push(fillWith); return slice; }); }, inject(memo, iterator, context) { iterator = iterator.bind(context); this.each((value, index) { memo = iterator(memo, value, index); }); return memo; }, invoke(method) { var args = $A(arguments).slice(1); return this.map((value) { return value[method].apply(value, args); }); }, I've obviously also used method definition shorthand by changing any ": function (" occurrences in the original prototype code to just "(". Without a leading keyword, it's harder to find the functions. Not impossible, not saying this is a deal breaker. But it is harder. /be Isaac Schlueter wrote: > > > On Tue, Mar 6, 2012 at 10:07, Thaddee Tyl <thaddee.tyl at gmail.com > <mailto:thaddee.tyl at gmail.com>> wrote: > > An interesting property of this syntax is that anonymous functions can > > be written this way: > > myList.forEach(λ (item) { doWith(item) }) > > (it can also be `lambda (item) { ... }`) > > > Yes, any valid function identifier could be used, because it's not > actually a keyword. > > _ (arg) { ... } > f (arg) { ... } > $ (arg) { ... } > ƒ (arg) { ... } > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss