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 <[email protected]> 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 <[email protected]> > wrote: > >> On 16 July 2015 at 17:29, Mark S. Miller <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
