I would prefer
var a = `This is a template string.`
`Even though each line is indented to keep the`
`code neat and tidy, the white space used to indent`
`is not in the resulting string` keepindentation`;
as a multiple line string,
2014-09-11 13:55 GMT+08:00 Sebastian Zartner
Hi guys.
Notice we are dealing with literals and I would want to keep the strings as
literal as possible so I think this is a syntax issue as the programmatic
solution like regexp substitution is always available.
My proposal:
var s = `This is a multiline
string. It keeps literal unless
On Thu, Sep 11, 2014 at 12:02 AM, Kevin Smith zenpars...@gmail.com wrote:
There's a difference between ZOMG WORKING IN SECRET and talking to
people and working on something privately that is still being fleshed out.
Hmmm... In many other circles talking to people and working on
something
The tag goes at the front. What's missing from the design that can't be
provided as a standard exported deindent function?
/be
Sebastian Zartner wrote:
var a = `This is a template string.
Even though each line is indented to keep the
code neat and
nope, looks like you forgot (sad) parenthesis :P
My point was that Array extras have this second argument there to pass a
context and fat arrow, as opposite of the thin one, would make that
parameter misleading/confusing/pointless (same as bind would but fat makes
it easier to mistake the intent)
but only one made it ... I am not comparing but many developers are already
confused about fat not behaving like thin.
Yes, thin should be part of ES6 ... it's way easier to spec as just regular
anonymous `function` shortcut , I still don't understand why it has been
left out.
The `function`
for record sake, this is my complain on missingn - better explained:
https://gist.github.com/qubyte/43e0093274e793cc82ba#comment-1292183
Rick kindly ensured me that it will be discussed for ES7, I see that too
late for such little improvement able to cover 100% of use cases (
including
On Thu, Sep 11, 2014 at 12:56 AM, Mark S. Miller erig...@google.com wrote:
If there are no objections to recommending .js vs .jsm in this informal
way, I propose that we place it there.
FWIW, .jsm extension is currently used as a convention in XUL for denoting
JavaScript modules (not the
Looking at my project (in which asynchronous calls are entirely done
via generators), I can't see how async/await would simplify code for
end-users like me (application programmers).
End users write the spawn()/Q.async()/co() wrapper *at most* one
single time in an application:
1. When using a
@Jasper: because tuples can be insanely optimized - their immutability
(including fixed length) removes almost any overhead (JS objects
overhead is quite big). Of course, modern engines can optimize array
to be
@Jeremy: consistency with other immutable primitives and frozen objects.
`(function()
I'm not an expert but the JIT could keep all the lists as tuples until a
modification is performed and then prevent further optimisation.
I don't know if current JITs are already doing this way.
On 10 Sep 2014 23:42, Jeremy Martin jmar...@gmail.com wrote:
Michal - Why have it only throw in
Yes, async/await solves one problem in particular that generators alone
cannot—the ability to `await` some asynchronous value from within a true
generator (one yielding actual values, not a coroutine yielding promises or
thunks into a trampoline). These coro trampolines are a clever hack, but
the
There are several problems solved by async/await instead of twisting generators:
1. What if you wanted to use generators for lazy sequences (iterables), instead
of asynchronicity? If your framework assumes all generators are for async, you
lose the original use case of generators.
2. Say what
You can inject the proto but that's not really subclassing ... You know, I'm starting to think that injecting proto is actually the right way to do subclassing. It preserves [[Class]], it doesn't depend on `new`, etc. Here is some code I checked with:
Also, see https://github.com/lukehoban/ecmascript-asyncawait/issues/14 for
previous discussion.
On Thu, Sep 11, 2014 at 8:42 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
There are several problems solved by async/await instead of twisting
generators:
1. What if you wanted to use
await has also another problem in that if somewhere, deep down the call
stack, something is intending to do async, then up the entire call stack
everywhere you've got to insert await. It's a bit of a headache for code
maintenance (hello bicycle repair man jam session), and it's also fairly
On Thu, Sep 11, 2014 at 6:20 AM, Florian Bösch pya...@gmail.com wrote:
await has also another problem in that if somewhere, deep down the call
stack, something is intending to do async, then up the entire call stack
everywhere you've got to insert await. It's a bit of a headache for code
A - B - C - D - E changes to
A - B - C - D - async E and causes
A await - B await - C await - D await - async E
And of course if A, B, C or D is used anywhere else it percolates trough
the entire call graph.
Trying to protect people from interlaved code execution effects is noble.
But doing so
Furthermore, since await is call graph infectious, for those really wanting
to use it, it means that before long, await is written before every single
function call. Which makes no sense.
On Thu, Sep 11, 2014 at 4:22 PM, Florian Bösch pya...@gmail.com wrote:
A - B - C - D - E changes to
A - B
I work on Traceur's loader and participate in the loader discussions on
es-discuss. I find the lack of engagement by the developers of the loader
disheartening. The long, painful, sometimes contentious discussions about
classes yielded an outstanding design that works well. Is the loader on
track
On Thu, Sep 11, 2014 at 7:22 AM, Florian Bösch pya...@gmail.com wrote:
A - B - C - D - E changes to
A - B - C - D - async E and causes
A await - B await - C await - D await - async E
And of course if A, B, C or D is used anywhere else it percolates trough
the entire call graph.
Trying
On Sep 11, 2014, at 1:05 AM, Brendan Eich wrote:
The tag goes at the front. What's missing from the design that can't be
provided as a standard exported deindent function?
exactly:
var a = dontIndent
`This is a template string.
Even though each line
The problem of code interleaving isn't on a fundamental level (like with
threads). Threads are a very different best, that interlave at random
points in time, and hence require some heavy lifting by the environmnet/OS
to not immediately fall flat.
Cooperative multitasking between I/O primitives
At the last TC39 meeting (
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#44-instantiation-reform-review-create-design-rationale-and-possible-alternatives
and
On 9/11/14, 10:22 AM, Florian Bösch wrote:
A - B - C - D - E changes to
A - B - C - D - async E and causes
A await - B await - C await - D await - async E
And of course if A, B, C or D is used anywhere else it percolates
trough the entire call graph.
Sort of true, but this is no worse than
See https://brendaneich.com/2011/01/harmony-of-my-dreams/ tuples --
much of the rest is in ES6 or out of date (e.g. = functions supersede
#(){}), but tuples and records might still happen, based on my spider-sense.
/be
___
es-discuss mailing list
John Barton wrote:
The long, painful, sometimes contentious discussions about classes
yielded an outstanding design that works well.
In no sense were ES6 classes designed by es-discuss draw-out contentious
painful committee.
If you meant by yielded reviewed the design after champions had
On Sep 10, 2014, at 6:24 PM, Boris Zbarsky wrote:
On 9/10/14, 5:48 PM, Allen Wirfs-Brock wrote:
Why not just us ES as the specification language for most things in the
WebIDL world? Or if not full ES, a simplified form Spec-ES.
There are a few issues with using ES for specifying Web IDL.
On 9/11/14, 1:47 PM, Allen Wirfs-Brock wrote:
To clarify, I wasn't necessarily talking about using ES to specify Web IDL.
Rather I meant using ES as an alternative to pseudo code for specifying the
semantics of APIs defined with Web IDL interfaces.
Ah, I see.
Yeah, I'm not sure how much
On 9/11/14, 12:35 PM, Allen Wirfs-Brock wrote:
https://gist.github.com/allenwb/291035fbf910eab8e9a6 summaries the
main syntactic changes since the meeting and provides rationales them.
These features are common to both alternates. this is a good place to
start, after reading the meeting
oh oops! they are supposed to be new^. Will fix...
On Sep 11, 2014, at 12:55 PM, Boris Zbarsky wrote:
On 9/11/14, 12:35 PM, Allen Wirfs-Brock wrote:
https://gist.github.com/allenwb/291035fbf910eab8e9a6 summaries the
main syntactic changes since the meeting and provides rationales them.
On Wed, 10 Sep 2014, Rob Sayre wrote:
On Fri, Aug 29, 2014 at 2:23 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 29 Aug 2014, David Herman wrote:
It's still not completely clear to me what your use cases are, so
I'm not sure exactly how much user-visible API you need.
My goal is to
Ian Hickson wrote:
I must admit though that while I initially assumed that this would be an
obvious goal that browser vendors would all be eager to reach, I have yet
to see anyone indicate that they're interested in this. So maybe it is in
fact not a goal. I don't know.
I think it must be a
On Thu, 11 Sep 2014, Brendan Eich wrote:
Ian Hickson wrote:
I must admit though that while I initially assumed that this would be an
obvious goal that browser vendors would all be eager to reach, I have yet
to see anyone indicate that they're interested in this. So maybe it is in
fact not
Did I say a nonsense about JIT and lists? Indeed, AFAIK, making:
var tuple = Object.freeze([1, 2]);
It is like having a tuple and the JIT could realize the object is frozen
and perform the required optimizations.
On Thu, Sep 11, 2014 at 7:28 PM, Brendan Eich bren...@mozilla.org wrote:
See
It seems like new^ is a new argument that is implicitly passed to all functions.
What does new^ mean in an arrow function?
How does new^ interact with a proxy whose target is a constructor?
-j
On Thu, Sep 11, 2014 at 3:00 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
oh oops! they are
I meant to add: I think it's *great* that we're still iterating on
this. Surely there's a way.
On Thu, Sep 11, 2014 at 3:37 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
It seems like new^ is a new argument that is implicitly passed to all
functions.
What does new^ mean in an arrow
I'd like to inject my own experience into this discussion.
I am the author of streamline.js, a smalll extension to JavaScript which
adds async/await semantics to the language. I developed this language
extension in January 2011 and we have been using it since then in a large
project (new web
On Thu, Sep 11, 2014 at 4:41 PM, Bruno Jouhier bjouh...@gmail.com wrote:
I think that Mark Miller nails it really well:
The cost of making atomicity cheap is that interleaving points must be
made explicit. With callbacks, this cost is quite high. Promises reduce this
cost substantially.
On Sep 11, 2014, at 1:37 PM, Jason Orendorff wrote:
It seems like new^ is a new argument that is implicitly passed to all
functions.
What does new^ mean in an arrow function?
How does new^ interact with a proxy whose target is a constructor?
see
I forgot to mention performance.
streamline has been an interesting playground to test performance because
it supports 3 different backends:
- pure callbacks with a sophisticated CPS transform
- fibers (much simpler transform)
- generators (transform is similar to fibers, runtime is a
Ian Hickson wrote:
On Thu, 11 Sep 2014, Brendan Eich wrote:
Ian Hickson wrote:
I must admit though that while I initially assumed that this would be an
obvious goal that browser vendors would all be eager to reach, I have yet
to see anyone indicate that they're interested in
On Thu, Sep 11, 2014 at 5:27 PM, Bruno Jouhier bjouh...@gmail.com wrote:
If async/await is baked into the language VM implementers will be able to
choose between different strategies: callbacks, single frame continuations,
deep continuations, ...
...and transactional speculation. Or at least,
Recently, `String(symbol)` has been modified in order to not throw, on the
ground that it is an explicit conversion, and a safer one than `.toString()`.
[1]
What about symbols in untagged templates?
function foo(num, sym) {
if (__debugMode)
window.alert( `Got arguments:
Claude Pache wrote:
Recently, `String(symbol)` has been modified in order to not throw, on the
ground that it is an explicit conversion, and a safer one than `.toString()`.
[1]
And to cite the hazard, because obj[name +''] where name is a non-symbol
must continue to work as it has, but if
Ob. bikeshed: why not `new?` as the magic pair of tokens? Seems
unambiguous given `new` as a reserved identifier since dayone.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, 11 Sep 2014, Brendan Eich wrote:
It may be that you have to keep compatibility, which means larger API
surface over time, new more-unified and old less-unified subsystems
coexisting. That's how the Web has grown in other areas. Original DOM
didn't reflect all elements; in the '90s
On Sep 11, 2014, at 3:03 PM, Brendan Eich wrote:
Ob. bikeshed: why not `new?` as the magic pair of tokens? Seems unambiguous
given `new` as a reserved identifier since dayone.
/be
new? would be fine,. Actually better. But we shied away from it, so as to
not impinge upon future use of
Le 12 sept. 2014 à 00:03, Brendan Eich bren...@mozilla.org a écrit :
Ob. bikeshed: why not `new?` as the magic pair of tokens? Seems unambiguous
given `new` as a reserved identifier since dayone.
If one day we introduce the so-called existential operator `foo?.bar`, it will
be quite
On Sep 11, 2014, at 2:59 PM, Brendan Eich wrote:
Claude Pache wrote:
Recently, `String(symbol)` has been modified in order to not throw, on the
ground that it is an explicit conversion, and a safer one than
`.toString()`. [1]
And to cite the hazard, because obj[name +''] where name is a
Allen Wirfs-Brock wrote:
new? would be fine,. Actually better. But we shied away from it, so as to not impinge
upon future use of ?. Even if there was no lexical ambiguity there might be conceptual
confusion with some future usage.
When last we considered refutable patterns, e.g., match
Claude Pache wrote:
Le 12 sept. 2014 à 00:03, Brendan Eichbren...@mozilla.org a écrit :
Ob. bikeshed: why not `new?` as the magic pair of tokens? Seems unambiguous
given `new` as a reserved identifier since dayone.
If one day we introduce the so-called existential operator `foo?.bar`, it
Ian Hickson wrote:
On Thu, 11 Sep 2014, Brendan Eich wrote:
It may be that you have to keep compatibility, which means larger API
surface over time, new more-unified and old less-unified subsystems
coexisting. That's how the Web has grown in other areas. Original DOM
didn't reflect
Le 26 août 2014 à 17:39, Jeff Walden jwalden...@mit.edu a écrit :
On 08/12/2014 11:07 PM, Allen Wirfs-Brock wrote:
sounds good to me, I'll update the spec. accordingly
On Aug 12, 2014, at 7:39 PM, Erik Arvidsson wrote:
I was suggesting that String(symbol) should not throw.
This can be
The tag goes at the front.
I know. I didn't see this functionality as a tag, though, but rather as a
flag for the client. Having this functionality available as a tag has some
consequences. See below.
What's missing from the design that can't be provided as a standard
exported deindent
55 matches
Mail list logo
