Generalize do-expressions to statements in general?
matthewwrobb at gmail.com
Fri Jul 17 16:03:00 UTC 2015
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:
- 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>
>> 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
>> 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).
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss