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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
