Yet they are cases where a block lambda isn’t suited and where a ‘classic’
function is just too long to type (and would hurt performance as well). Look
back in the thread for a sample. (Mainly: cases involving a ‘return’ in a loop
or in a nested statement can’t be solved well using block-lambda).
Block lambda is not the solution since it wasn’t written to solve the cases
where we traditionnaly use a 'local function’, but to solve new use-cases where
we want our function to continue to run inside a function structure, or
asynchronously. The old cases where we use “function() { ... { ... return; }
... }” are not covered properly by block lambda, nor are intended to.
From: Axel Rauschmayer
Sent: Thursday, January 19, 2012 10:14 PM
To: Brendan Eich
Cc: Andreas Rossberg ; François REMY ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
FTR: With block lambdas and object literal extensions, I wouldn’t want/need a
function shorthand. I thought I had seen an opportunity for a more compact
syntax (if and only if function shorthands are needed), but was wrong. Sorry.
Suggestion: a community-edited page where we collect the rejected syntaxes (=>
less running in circles) – simply copying emails (such as yours below) there
would probably suffice.
On Jan 19, 2012, at 20:27 , Brendan Eich wrote:
Axel Rauschmayer <mailto:a...@rauschma.de>
January 19, 2012 9:31 AM
Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you
want anything else, you can use a traditional function. Then the above syntax
as the only function shorthand would be OK.
First, #(params) { body } was proposed by Arv and Alex:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Arv and Alex feel strongly that the shorter function syntax (anything
shortening 'function' syntax) must not freeze by default.
There was lack of clarity about whether completion value as implicit return
value was part of the proposal. If so, controvery, since there is a completion
value leak hazard. TC39 seems to agree the solution there is something with
different look & feel, such as block-lambdas.
But, making a one-char grawlix shorthand for 'function' while still requiring
'return' is not considered enough of a shorthand. A possible cure here is to
support an alternative body syntax: #(params) expr. However, this inverts
precedence if done naively. It also runs into trouble trying to prefer an
object literal over a block statement. I've worked on both of these in the
context of
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
This superseded shorter_function_syntax, but ran into grammatical issues that
have vexed it.
But notice that throughout this, no one advancing a proposal advocated
freezing by default. JS developers use function objects as mutable objects. Not
just to set .prototype, also to decorate with ad-hoc and meta-data properties.
Freezing is not wanted by default.
I agree that for block-lambdas it's easier to say "freeze by default". For
merely "shorter function syntax", no. Functions are mutable objects by default
in JS. This matters for minifiers, which may not be able to see all the
mutations but would love to use shorter syntax for 'function' syntax, blindly.
/be
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
