Generalize do-expressions to statements in general?
Mark S. Miller
erights at google.com
Thu Jul 16 15:29:25 UTC 2015
I echo this. E is a dynamic language with many similarities with JS,
including a similarly C-like syntax. In E I use
everything-is-a-pattern-or-expression all the time. When I first moved to
JS I missed it. Now that I am used to the JS statements-are-not-expressions
restrictions, I no longer do, with one exception:
When simply generating simple JS code from something else, this restriction
is a perpetual but minor annoyance. 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.
On Thu, Jul 16, 2015 at 6:38 AM, Andreas Rossberg <rossberg at google.com>
> On 16 July 2015 at 15:21, Bob Myers <rtm at gol.com> wrote:
>> With all "do" respect, none of this syntax tinkering makes any sense to
>> I've been programming JS for 15 years and never noticed I needed a try
>> block that returns a value.
>> Long ago I programmed in a language called AED that had valued blockl,
>> which I was quite fond of, but never felt the need for that in JS for
>> whatever reason.
> I've been programming in C++ for 25 years, and didn't have much need for a
> try expression or nested binding either.
> I've also been programming in functional languages for 20 years, and need
> them on a regular basis.
> It all depends on how high-level your programming style is. Also, Sapir
> Whorf applies as usual.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss