Generalize do-expressions to statements in general?

[Matthew Robb]

Just wanted to say I was playing around with the idea of using parens as
block-expressions this morning and I REALLY like it. It doesn't feel like
an added feature at all it just seems natural since blocks don't normally
produce a value.

The questions I think that remain are:
1) return?
2) yield?


- Matthew Robb

On Fri, Jul 17, 2015 at 9:27 AM, Mark S. Miller <erights at google.com> wrote:

> I don't see a conflict between return and being an expression language.
>
> Smalltalk and E both have return. In Scheme terms, this is simply
> call-with-escape-continuation. Gedanken again was probably the first to
> have this right with their "escape" construct, which E borrowed. E's method
> syntax desugars into a more primitive method syntax plus a top level escape
> form defining an escape continuation. E's return desugars into calling the
> escape continuation.
>
> The problem with return is orthogonal -- that we chose to define arrow
> functions so that are their own return point, rather that having return be
> TCP to the enclosing method. In escape continuation terms, we made the
> mistake of shadowing the outer escape continuation binding. But making JS
> into an expression language would not make this worse.
>
>
>
> On Fri, Jul 17, 2015 at 2:14 AM, Andreas Rossberg <rossberg at google.com>
> wrote:
>
>> On 16 July 2015 at 17:29, Mark S. Miller <erights at google.com> wrote:
>>
>>> When simply generating simple JS code from something else, this
>>> restriction is a perpetual but minor annoyance.
>>>
>>
>> Indeed, one motivation for do-expressions is better support for compilers
>> targeting JS. And for some of those, not being able to mix statements and
>> expressions, not having try inside expressions, and not having support for
>> nested bindings, can be very tough, because it prevents compositional
>> translation.
>>
>>
>> By itself, I would agree that this annoyance is not important enough to
>>> add a new feature. However, if rather than "adding a feature", we can
>>> explain the change as "removing a restriction", then JS would get both
>>> simpler and more powerful at the same time. Ideally, the test would be
>>> whether, when explaining the less restrictive JS to a new programmer not
>>> familiar with statement languages, this change results in one less thing to
>>> explain rather than one more.
>>>
>>
>> I doubt that will work, because there still will be plenty of artefacts
>> and irregularities of a statement language that they will have to
>> understand. Pretending it's an expression language will rather cause more
>> confusion than less, because it isn't (for one, you can't get rid of the
>> 'return' statement).
>>
>> /Andreas
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/ee09b07b/attachment.html>