Yes, I'm planning to prepare a proper spec for the September meeting. I'm
also hoping we get a prototype impl in V8 some time later this year,
although I'd rather not promise anything.
Cool - looking forward to it!
___
es-discuss mailing list
On 26 June 2015 at 04:08, Kevin Smith zenpars...@gmail.com wrote:
I think do expressions are go for ES7 but they need re-championing,
and implementation. I'll stir the pot.
I think Andreas was interested at some point?
Yes, I'm planning to prepare a proper spec for the September meeting.
Hello!
Though this is a kind of syntax is probably macroable, interesting idea
appeared in my mind regarding let blocks, so I would show it here, maybe
it can actually be interesting for others as well.
The idea is to use existing let statement and extending it so one can
include { ...
Matthew Robb wrote:
I feel like this would just get confused with object destructuring.
Not just confused -- it is fatally ambiguous.
I think do expressions are go for ES7 but they need re-championing,
and implementation. I'll stir the pot.
/be
I feel like this would just get confused with object destructuring.
On Jun 25, 2015 5:17 PM, Herby Vojčík he...@mailbox.sk wrote:
Hello!
Though this is a kind of syntax is probably macroable, interesting idea
appeared in my mind regarding let blocks, so I would show it here, maybe it
can
On Thu, Jun 25, 2015 at 6:20 PM, Brendan Eich bren...@mozilla.org wrote:
I think do expressions are go for ES7 but they need re-championing, and
implementation. I'll stir the pot.
Might this include something like the following form?: ` do(let x = 1) {}
`. Seems like that might satisfy
I think do expressions are go for ES7 but they need re-championing,
and implementation. I'll stir the pot.
I think Andreas was interested at some point?
I've long been interested in the possibility of a do async as well. : )
___
es-discuss mailing
I agree completely, and I fully apologize. Starting the thread this way
was inappropriate, at least without some mitigating text which I did not
think to add. I like the fact that we are all civil to each other here and
try to keep the environment welcoming and friendly. Please no one take my
Just to wrap this thread up, quoting myself from another thread:
In any case, I won't push my proposal anymore.
But for posterity sake, wanted to make one last comment as to why the various
suggestions for IIFE's and arrow expressions are inappropriate for the task:
they change (hijack)
Hey Kyle
True for `continue` and `break`, but maybe it’s about time we stop using these
archaic control structures anyway :)
As for `return` I don’t see what’s the problem if you return your value inside
the IIFE as well.
Regards
On Jun 20, 2015, at 10:10 PM, Kyle Simpson get...@gmail.com
I agree completely, and I fully apologize. Starting the thread this way was
inappropriate, at least without some mitigating text which I did not think
to add. I like the fact that we are all civil to each other here and try to
keep the environment welcoming and friendly. Please no one
While I am also concerned with the problem of ever-expanding
languages because the larger they grow, the harder they are to
learn, and the harder it is to read someone else's code which
uses unfamiliar features, there are other issues that are
equally important.
I find the most unappreciated
On Sat, Jun 20, 2015 at 11:18 AM, Bill Frantz fra...@pwpconsult.com wrote:
While I am also concerned with the problem of ever-expanding languages
because the larger they grow, the harder they are to learn, and the harder
it is to read someone else's code which uses unfamiliar features, there
On Fri, Jun 19, 2015 at 7:23 AM, Scott Sauyet sc...@sauyet.com wrote:
I think the difference between your list and mine exemplifies the tragedy
of the commons as so well described by Mark. Although we both share a
liking for modules and imports, my favorite ES6 feature is the arrow
Someone just brought https://news.ycombinator.com/item?id=9742823 to my
attention. It says:
I like the author’s remarks and philosophy about keeping JavaScript small,
but I thought the opening was remarkably uncharitable. The specific person
and the specific feature are quite irrelevant to the
This is just a heads up for context that someone published a link to Mark's
post in HN here: https://news.ycombinator.com/item?id=9738866 in case we
get any more new people posting in the thread.
-
Features like classes and `let` are very often criticised and often
languages that did not
Greg McLeod cle...@gmail.com wrote:
I really really love JS (it's so fun!), and while there are many features
in ES6 that I think are great (such as classes, modules, and import syntax)
there are things that quite frankly scare me quite a bit. Such examples
include destructuring and arrow
On 19 June 2015 at 10:06, Alexander Jones a...@weej.com wrote:
If people are unable to internalize the whole language, then surely we
need a way to remove cruft and idiosyncracies in it, lest the language
stagnate beyond repair.
Removing var, typeof, exotic objects, function declarations,
I don't think anyone is frightened about removing these things. The TC
has a commitment not to break the internet, by removing something like
`var` or `typeof` you're disabling *billions* of people who are using the
internet - it would very much literally break the internet. Even if the
TC
If people are unable to internalize the whole language, then surely we need
a way to remove cruft and idiosyncracies in it, lest the language stagnate
beyond repair.
Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
enumerable properties, are just a few examples of things we
An interesting wrinkle in language design has been the rise of
sophisticated linting and style tools like `jscs`. If you wish to
deprecate `var` for instance, it is straightforward to write a jscs module
to enforce that. Further, several large communities (node, wikipedia, etc)
have published
I do not share Mark's view. Contra his sentiment, I was using the small
version of JS for many years and noted that most non-trivial uses required
finding or building a library. That choice of library (which exist to fill
in platform and language deficiencies) leads to a a split in common use
On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell slightly...@google.com
wrote:
I do not share Mark's view. Contra his sentiment, I was using the small
version of JS for many years and noted that most non-trivial uses required
finding or building a library. That choice of library (which exist to
In all of the examples I mentioned there are other, more predictable
alternatives already in the language. Do we really expect JavaScript
programmers in 2025 to remember to use Number.isNaN instead of isNaN? I
really don't understand why people think use strict was OK to pull off,
but further
On Jun 19, 2015, at 10:29 AM, Alex Russell wrote:
I do not share Mark's view. Contra his sentiment, I was using the small
version of JS for many years and noted that most non-trivial uses required
finding or building a library. That choice of library (which exist to fill in
platform and
It sounds like you are advocating for a larger standard library in JS. I
think many on this thread are focusing on whether more syntax features
should be added.
On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell slightly...@google.com
wrote:
I do not share Mark's view. Contra his sentiment, I was
Indeed Mark.
It took some of us longer to unwind those features out of our codebase than
others.
One of my biggest concerns in switching to the yearly numbering system is
the same as Allen Kevin: there will be pressure to ship new features
every year (as if we're a software company that wants
On Jun 19, 2015, at 11:24 AM, Kevin Smith wrote:
ES needs to evolve more rapidly than once every 5-15 years. The yearly
update plan is good, but that doesn't mean we should be rushing proposals
(particularly complex ones) through the process in order to catch the next
yearly release.
use strict was only a breaking change regarding ES3 code that
coincidentally happened to use exactly this literal string as a do-nothing
expression statement in exactly this position. In all of the web, we have
not run across a single incident of this happening accidentally.
For the record, not
On Jun 19, 2015, at 2:53 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jun 19, 2015, at 11:24 AM, Kevin Smith wrote:
ES needs to evolve more rapidly than once every 5-15 years. The yearly
update plan is good, but that doesn't mean we should be rushing proposals
(particularly
Benjamin Gruenbaum wrote:
Apart from complicating the engine and the grammar - what advantage does the
second version have over the first one? Why do you prefer it to the first one?
(Genuinely asking)
I'm also not aware of any other languages that provide this (although that's
not a huge
(function (a, b, c) {
}(2))
The main disadvantage of that style over the one I'm advocating for is that it
visually separates the variable declaration (`a`) from its value initialization
(`2`). If there's 5, 10, or more lines of code in between them, it makes it
much harder to figure out
Be aware that the way you utilize 'let' will be a breaking change. In ES5 and
ES6
In addition to the fact that this feature is long since co-existing in FF and
doesn't seem to have broken the web, IIUC, there was already a breaking
change in ES6, with `let` and destructuring:
```js
let[x] =
Benjamin Gruenbaum wrote:
From: Kyle Simpson get...@gmail.com mailto:get...@gmail.com
To: es-discuss@mozilla.org mailto:es-discuss@mozilla.org
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
Cc:
Date: Thu, 18 Jun 2015 07:34:28 -0500
Subject: Re: revive let blocks
(function (a, b, c
Apart from complicating the engine and the grammar
I've tried to figure out what complications it introduces. In my imperfect
analysis, it hasn't seemed like much. I've written a transpiler tool[1] that
finds `let (x..) { .. }` occurrences and changes them to `{ let x.. .. }`. It
was pretty
From: Kyle Simpson get...@gmail.com
To: es-discuss@mozilla.org es-discuss@mozilla.org
Cc:
Date: Thu, 18 Jun 2015 07:34:28 -0500
Subject: Re: revive let blocks
(function (a, b, c) {
}(2))
The main disadvantage of that style over the one I'm advocating for is
that it visually separates
Apart from complicating the engine and the grammar - what advantage does the
second version have over the first one? Why do you prefer it to the first one?
(Genuinely asking)
I'm also not aware of any other languages that provide this (although that's
not a huge issue).
On Jun 18, 2015, at
Be aware that the way you utilize 'let' will be a breaking change. In ES5 and
ES6```let(a=1) {}```is valid and it is a call to let with one argument followed
by a block. Your suggestions will turn it into a let-block. In ES6 let is
considered as an identifier and the meaning is created by
Another way: Instead of using `let` at all, why not creating a function and
pass it your `a`, `b` and `c` as arguments.
Nowadays I try to program without explicitly declaring any variables, hence my
suggestion.
```js
(function (a, b, c) {
}(2))
```
If you can post a more concrete
I see what you mean.
I always try to favor functional-style JavaScript (creating a big expression
composed
of several functions, both as arguments or declared somewhere, using recursion
instead of keeping state, not using control structures, no variables, etc),
hence my
suggestion.
On 18 Jun 2015, at 15:59 , Bradley Meck bradley.m...@gmail.com wrote:
(a=1)={
console.log(a)
}()
Is less verbose than an IIFE and keeps `this` the same. Also keeps the
initialization and init of the variable in the same place.
Neat trick. Caveat – you need parentheses around the
On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson get...@gmail.com wrote:
I'd like to ask if there's anyone on TC39 that would be willing to
champion a proposal to add the let-block (let-statement) syntax?
I am not. Further, if anyone were, I would work to kill it. Here's why.
The Algol,
(a=1)={
console.log(a)
}()
Is less verbose than an IIFE and keeps `this` the same. Also keeps the
initialization and init of the variable in the same place.
On Thu, Jun 18, 2015 at 8:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/18/15 9:01 AM, Kyle Simpson wrote:
In addition to the
On 6/18/15 9:01 AM, Kyle Simpson wrote:
In addition to the fact that this feature is long since co-existing in FF and
doesn't seem to have broken the web
Firefox doesn't ship let support on the web by default yet. For
example, this HTML:
scriptlet x = 5;/script
will result in:
On Thu, Jun 18, 2015 at 9:54 AM Boris Zbarsky bzbar...@mit.edu wrote:
On 6/18/15 9:01 AM, Kyle Simpson wrote:
In addition to the fact that this feature is long since co-existing in
FF and doesn't seem to have broken the web
Firefox doesn't ship let support on the web by default yet. For
Good points, Mark.
There are two better ways forward that I see:
1. Separate forms and make them compose well. Instead of let (x=y){z}
and the grammatically unsound let (x=y)x*x from ES4, given let in ES6,
and do expressions in ES7, declare victory and use `do { let x = y; z }`.
2. Sweet.js
On 6/18/15 11:30 AM, Rick Waldron wrote:
Strange, this works in the console, but not in a script
https://i.gyazo.com/e55d26495c3fe8b01938fe1b99664682.png
Yep, it's entirely possible the console opts in to let.
It also exposes some APIs that are not exposed in web pages by default
and a few
Very well said Mark! You've basically articulated what I've been thinking
for a few years now as someone lurking amongst these lists afraid to speak
up. Often times I've seen people's questions or criticisms get shut down
with a link to lmgtfy often followed by an emoticon or two, which doesn't
First of all, brilliant post Mark.
As a community, we need more of a shared sense of panic about the size
that ES6 has already grown to. Ideally, that panic should increase, not
decrease, with further growth from here as our size approaches the point of
no return.
As a community, we do - if you
I don't think JS needs many more changes as it is today.
I mean it does, but mostly on browsers land, not in its core
On Thu, Jun 18, 2015 at 7:27 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I like Mark's post too, and if I might ...
Features like classes and `let` are very
It seem semi-obligatory at this point to cite Growing a Language, by Guy
Steele.
https://www.youtube.com/watch?v=_ahvzDzKdB0
Transcript at http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
(if you must).
I tend to agree with the idea that at this point we need *means to grow
syntax*
I like Mark's post too, and if I might ...
Features like classes and `let` are very often criticised and often
languages that did not add these features and are considered 'well
designed' are given in comparison (Python's lack of block scoping for
instance).
thing is, ES6 brought in many things
On 18 June 2015 at 19:26, Benjamin Gruenbaum benjami...@gmail.com wrote:
This is a mailing list comprised of people who typically have a much
better understanding of the language and its corners than most (even
professional) developers have (and dare I say, are interested in or care
about
On Thu, Jun 18, 2015 at 12:55 PM Boris Zbarsky bzbar...@mit.edu wrote:
On 6/18/15 11:30 AM, Rick Waldron wrote:
Strange, this works in the console, but not in a script
https://i.gyazo.com/e55d26495c3fe8b01938fe1b99664682.png
Yep, it's entirely possible the console opts in to let.
It also
I suspect that (2) deserves a look in about a year, but welcome thoughts
from Tim Disney et al (@natefaubion @jlongster).
Yep, that sounds about right.
Sweet.js design is all about dealing with use-cases like this; start with a
small core and then grow the syntax needed for your domain.
If
On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
On 18 June 2015 at 19:26, Benjamin Gruenbaum benjami...@gmail.com wrote:
This is a mailing list comprised of people who typically have a much better
understanding of the language and its corners than most (even professional)
developers
Preach it, brother!
I'd like to jump on the bandwagon of Mark's concern about the
death-of-a-thousand-cuts phenomenon.
It is far too easy to make a bunch of small additions, each of which is
individually worthy and justifiable, that collectively add up to a sum total
that is not so worthy or
I've worked with sweet.js a lot, and someone pointed this email out to
me. I can't agree more. I love all the ES6 features, and some of ES7,
but looking at some of the future ES7 stuff (like decorators, etc)
makes me wonder what a finished JavaScript will look like. I'm not
bashing on decorators
And I occasionally have to go and look up details.
You know nothing Allen Wirfs-Brock (cit)
On Thu, Jun 18, 2015 at 8:55 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
On 18 June 2015 at 19:26, Benjamin Gruenbaum
I'd like to ask if there's anyone on TC39 that would be willing to champion a
proposal to add the let-block (let-statement) syntax?
I currently write my block-scoped declarations as:
```js
{ let a = 2, b, c;
// ..
}
```
I do this because I want to be in the habit of always putting my
60 matches
Mail list logo
