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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
