Function Syntax

Brendan Eich brendan at mozilla.com
Wed May 11 10:16:33 PDT 2011


On May 11, 2011, at 9:53 AM, Brendan Eich wrote:

> 1. E is an expression language. JS would need opt-in syntax to make a sub-language (e.g. arrow function bodies) an expression language, and you'd still have plausible objections that with statements on the outside and expressions on the inside, programmers would not mind the gap and make both capability-leak and undefined-return bugs.
> 
> 2. Based on (1), we don't know why it became conventional (but not mandatory) in E that "blocks were rarely passed as first class values; and the control abstractions themselves AFAIK never leak them." The E experience is suggestive but mainly due to (1), curse JS's Java/C patrimony, inconclusive.

Beyond the muddy statement/expression JS waters, if I understand correctly, E has only convention on the side of blocks for control effects, whose completion results are the results of enclosing expressions, without capability leak bugs in practice.

It seems you want something less advisory, like always-on mandatory requirements that programmers annotate either return values or voided function calls. Do I have that right?


> 3. Blocks as implicitly quoted code could be like zero-argument lambdas, with break, continue, return, |this|, and |arguments| referred to any outer function or loop/switch statement. This suggests something like the Ruby-ish syntax Isaac sketched recently, mooted by various people in the past:
> 
>     array.map({|x| x * 2 }) // YAY!
> 
> Problems:
> 
> 3a. Basis case is {}, an object initialiser. Patchable by requiring {||}, but ugh.
> 
> 3b. The objection raised repeatedly when we discussed lambdas here, that return unwinding an outer function, or throwing an error if the outer function call has already returned, is as big a hazard and source of confusion as -- or bigger than! -- any completion-return downside.
> 
> 3c. The use of {| (possibly with space in between) is an unambiguous extension, but formal parameters inside |...| delimiters creates a problem for http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values. We would need the default value expression to be parenthesized if its precedence were | (bitwise-or) or looser.
> 
> Other than these, AFAICT blocks as lambdas offering shorter function-like syntax are pretty good. Should we reconsider them?

3c is really about how odd it is to put formal parameters inside anything other than (...).

3d. No |this| so no relief for functions as methods taking dynamic-|this| vs. functions with lexical |this|. We could work on 'function' syntax, and methods in extended object initialisers, but it seems to me the block syntax would be wanted for "methods" too, given how long 'function' is.

Adding something function-like, but not close enough, adds complexity. It's a bit odd that purely syntactic sugar is considered complex by some folks, but adding something new in both syntax and semantics is ok (if you come with the right history, e.g. Ruby). Well, maybe not odd, but not conclusive and something to be skeptical about, IMHO.

FTR I'm still in favor of shorter function syntax, working on better arrow-function grammar.

/be


More information about the es-discuss mailing list