Generalize do-expressions to statements in general?

[Mark S. Miller]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150717/e0d259c3/attachment.html>