(Almost) everything is expression

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Fri Nov 11 10:53:02 PST 2011


On 11.11.2011 22:48, gaz Heyes wrote:
> On 11 November 2011 18:29, Dmitry Soshnikov 
> <dmitry.soshnikov at gmail.com <mailto:dmitry.soshnikov at gmail.com>> wrote:
>
>     This is why the topic is called "*(Almost)* everything...". In
>     general case we may not include this case with label-statement
>     into proposal, since the construction you wrote isn't practice
>     IMO. But, we should consider also theoretical things and this case
>     it can be better to avoid the case at all then to solve it --
>     especially if there is no much profit in practice from it. Though,
>     if we can manage it, why not?
>
>
> Another thing isn't a block statement a no-op?  So :
> x={};
>
> x wouldn't be undefined or anything since a blank block statement 
> shouldn't return anything.

Obviously here it must be an object initialiser.

We basically may even restrict to use these statements as expressions 
only in some local expressions domain. E.g. only for assignments. There 
are alternatives which we shouldn't afraid to consider.

> Then if it returns undefined then how would a block statement actually 
> work:
> {}/1
>
> You'd have to make a block statement return undefined to make sense.
>
> So as you can see you are adding complexity to the syntax in both the 
> developer level and the sandboxing level. There are a ton of problems 
> this would create.

I don't see it. I started the proposal not because I thought out "some 
interesting stuff to discuss", but with concrete practical reason. I 
referred to Erlang where I everyday with much more convenience than in 
current JS may use all those complex expression on RHS.

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111111/f53ddde3/attachment.html>


More information about the es-discuss mailing list