Re: Enriched Descriptors, maybe ES7 ?

Andrea Giammarchi wrote: I'd love to know more about Tom experiments on this! With his polyfill on the original proxy implementation, now that I think about it. https://github.com/tvcutsem/harmony-reflect but originally http://es-lab.googlecode.com/svn/trunk/src/proxies/DirectProxies.js T

Re: Enriched Descriptors, maybe ES7 ?

Tom has experimented, IIRC. I don't know which implementations preserve extended property descriptor properties. /be Allen Wirfs-Brock wrote: Note that ES6 proxies as specified permits Object.defineProperty/getOwnPropertyDescriptor to pass custom attributes in property descriptors and even pa

Re: Object.getOwnPropertyDescriptors(O) ? // plural

Tom Van Cutsem wrote: Given that most of the functions that use [[OwnPropertyKeys]] need to either construct an array anyway, or want reliable results, I wonder whether we shouldn't just change [[OwnPropertyKeys]] to include the checks and return an array instead of an iterable. That way we avo

Re: Array.prototype.contains

Boris Zbarsky wrote: 1) document.styleSheetSets. 2) Microdata API. 3) Various places in indexeddb. 4) The DataTransfer API. 5) Some sort of offline resource list API that's not part of any standard I can find. #1 is not implemented by anyone but Gecko, and the spec is claiming it's a DOMStrin

Re: Object.getOwnPropertyDescriptors(O) ? // plural

André Bargull March 6, 2014 at 1:21 PM I would rephrase into this: if you need a getOwnPropertyNames trap, you might need for consistency a getOwnPropertySymbols independently from getOwnPropertyDescriptors since these methods are already available. While it shar

Re: Functions as blocks

On Mar 5, 2014, at 6:53 PM, Allen Wirfs-Brock wrote: > >> On Mar 5, 2014, at 6:23 PM, Brendan Eich wrote: >> >> John Barton wrote: >>> As you say "all browsers seem to allow it". Browsers made the mistake and >>> we should not go back now and bl

Re: Functions as blocks

John Barton wrote: As you say "all browsers seem to allow it". Browsers made the mistake and we should not go back now and blame developers on smaller sites because they use this kind of code. Make it a syntax error in modules and save yourself a lot of headaches. We could do this for sure, a

Re: Functions as blocks

Brian Terlson wrote: I haven't collected much data on this so I'm not sure what the prevalence is, Can you try to find some sightings in the wild? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 Tasks and TaskQueues

Tom Van Cutsem wrote: By contrast, terms such as "task" are used much more broadly (e.g. tasks scheduled on a thread pool). Yes, and a Task (e.g., in Rust; akin to goroutine in Go or Process in Erlang) can be suspended voluntarily. The use of "task" goes way back (multi-tasking). I think we

Re: Loader and Module as globals?

John Barton wrote: Well we have to make a choice. If we use Loader.prototype.Module, then we'll get System.Module by way of System being instanceof Loader. I don't see any reply to this message, but Loader and Module go in Reflect, last I heard. What you were worrying about does not make sense

Re: ES6 Tasks and TaskQueues

Allen Wirfs-Brock wrote: Now its just a word that we are assigning our own meaning to, so we can use "turn" if we want. But is that equivalence of "turn" and "task" really what you're used to, and something whose meaning is intuitive enough? On naming, we can use Turn instead of Task if enou

Re: Array.of

Thanks for the pointer! I like Claude's use-case and recall Allen citing it too. So, two reasons: 1. Higher-order functional programming wants a function, not literal syntax. 2. Subclassing Array works too, thanks to ES6's class-side inheritance. /be Rick Waldron

Re: Array.from and sparse arrays

C. Scott Ananian wrote: The more this is discussed, the more I am convinced that the current "holes are evil" behavior of `Array.from` and the `ArrayIterator` is the correct thing. Once you start introducing holes, they crop up everywhere. Just mentally tell yourself that `Array.from` is a meth

Re: Fwd: .next('yo') in newborn generators

Andy Wingo wrote: Hi, I don't see the point of throwing an error when calling .next('foo') on a newborn generator. We don't throw an error on .next('foo', 'bar'), and unlike the case with most function calls there is no way to get the 'bar' when resuming a generator, as you don't have an argume

Re: What does "is not present" mean in spec algorithms?

No informative deed goes unpunished, especially (as in this case) if it has contradictory normative implications! This was the lesson of ECMA-357 (E4X), with its overdone informative prose which often contradicted the normative prose. /be Sent from my iPad > On Feb 21, 2014, at 3:29 PM, Allen

Re: Array.from and sparse arrays

Allen Wirfs-Brock wrote: 1. Array.from already produces sparse arrays from array-likes: Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2] So why it doesn't from sparse arrays? Perhaps, this is an inconsistency that should be corrected by changing the spec. to produce [1,2,undefined] in the ab

Re: What does "is not present" mean in spec algorithms?

On Feb 20, 2014, at 8:16 AM, Allen Wirfs-Brock wrote: > > Nope, it means that the length of the argument list is less than two, hence > an argument corresponding to 'deleteCount' was not passed. > > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-standard-built-in-objects >

Re: Fwd: .next('yo') in newborn generators

Bradley Meck wrote: If I am reading the spec right (and I may not be), only the generator should fail? The first call to gen().next(value) must have value be undefined, and the others do not check. I thought we agreed at the January 28 meeting to get rid of this error, but I can't find it i

Re: .next('yo') in newborn generators

Bradley Meck wrote: Digging up old threads, but is there a way to test for newborn generators? No. To my knowledge they are the only iterable that does not allow a value to be passed in at a specific time. What do you mean by "does not allow"? /be __

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

Claude Pache wrote: But I think that clarity can be improved by avoiding to obscure the intent by computation details. For my personal polyfill, I have found useful to abstract out the following steps, used (with slight variations) thrice in `Array.prototype.copyWithin` and twice in `Array.pro

Re: Promise.cast and Promise.resolve

Domenic Denicola wrote: Well, but you could just move the internal slot initialization into the constructor itself (as Scott has done in his es6-shim promises). Unlike e.g. `Array`, the objects returned by `Promise[@@create]` are not exotic objects; they are simply normal objects with some int

Re: Return value of spec setters?

David Bruant wrote: In practice, the returned value of setting is the value on the rhs of the =. var o = {set b(v){return 12;}} // this return statement is useless console.log(o.a = 13); // 13 console.log(o.b = 14); // 14 It might be useful to return a different value on setting.

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

C. Scott Ananian wrote: Are recordings available? http://www.infoq.com/presentations/State-JavaScript starting at 1:50 Youtube has more. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Andreas Rossberg wrote: On 15 February 2014 20:47, Brendan Eich wrote: > Using "-Speak" as a stem conjures Orwell. Not good. Ah, relax. Gilad Bracha even named his own language Newspeak. Yeah, but no "ECMA" -- the double-whammy. Self-mockery is good. I pay my

Re: Changing behavior of Array#copyWithin when used on array-like with negative length

C. Scott Ananian wrote: But as you point out, I don't think there's any actual behavior change, since everything washes out to `0` at the end. It's just a matter of writing a clearer more consistent spec. Yet in that light you still have a point, I think. Allen? /be __

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

C. Scott Ananian wrote: On Feb 15, 2014 9:13 AM, "Brendan Eich" <mailto:bren...@mozilla.com>> wrote: > Aside: "ECMASpeak" is neither accurate (we don't work for Ecma, it's JS not ES :-P), nor euphonious. I'm learning all sorts of things!

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Aside: "ECMASpeak" is neither accurate (we don't work for Ecma, it's JS not ES :-P), nor euphonious. But here's a pointer: C. Scott Ananian wrote: new string object. "new string primitive", because "string object" (especially with "new" in front) suggests new String('hi'). /be ___

Re: eval of let, etc. Was: Re: restrictions on let declarations

Allen Wirfs-Brock wrote: On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: > On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavi

Re: eval of let, etc. Was: Re: restrictions on let declarations

Allen Wirfs-Brock wrote: the various forms of eval are already micro-mode, so I'm not sure if those points are very relevant. No, the various forms of eval do not have non-local effects of the kind your #2 did! /be ___ es-discuss mailing list es-d

Re: eval of let, etc. Was: Re: restrictions on let declarations

Mark S. Miller wrote: I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I find it least surprising. "var"s hoist out of blocks. In non-strict code, "function"s leak out of blocks in ways that are hard to explain. I can understand non-strict direct eval as being block-li

Re: Loops, Let, Closures

Andy Wingo wrote: On Wed 12 Feb 2014 15:55, Brendan Eich writes: > Andy Wingo wrote: >> On Wed 12 Feb 2014 15:22, Thaddee Tyl writes: >> >>> >The following ES6 code's behaviour puzzled a few developers I know. >>> >The results

Re: Loops, Let, Closures

Andy Wingo wrote: On Wed 12 Feb 2014 15:22, Thaddee Tyl writes: > The following ES6 code's behaviour puzzled a few developers I know. > The results indicated below each snippet are run through > SpiderMonkey's implementation. SpiderMonkey's implementation of for-let is out of date, AFAIK.

Re: Another switch

Definitely good to see new languages being designed and implemented. JS is not going to break compatibility on the old fall-through behavior of switch, inherited from Java from C++ from C. All the C-like languages copy this flaw, because to do otherwise with the same keyword would be worse (co

Re: shorthand notation for attribute creation?

Good memory. This is all at esdiscuss.org in the meeting notes, but I can't google for ||= to save my life, even in Verbatim mode. Anyone? Of course the original proposal is still in strawman stage on the wiki: http://wiki.ecmascript.org/doku.php?id=strawman:default_operator /be Domenic Deni

Re: Promise.cast and Promise.resolve

Jonathan Bond-Caron wrote: Thoughts on adding options/flags Just say no. http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html This is a symptom. We are resisting the larger issue of "do both" or design-by-committee unioning or other such failure modes. /be _

Re: Promise.cast and Promise.resolve

David Bruant wrote: Le 07/02/2014 22:05, Brendan Eich a écrit : Kevin Smith wrote: - A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is a poor medium for

Re: Promise.cast and Promise.resolve

Kevin Smith wrote: If I may interject some opinions on process... Sure, it's es-discuss. Plus, you've earned your spurs. I'm not sure how this fits in with the new post-ES6 process, but from this one outsider's point of view: - A formal set of design goals should be completed and agreed upo

Re: Promise.cast and Promise.resolve

Tab Atkins Jr. wrote: The APIs for Caches and dealing with responses are designed so that they work nicely together, acting the same way whether you pass a Response or a Promise. So you can often respond to requests with a simple "e.respondWith(cache.get('foo'))" and it Just Works®. Nice. Bu

Re: Promise.cast and Promise.resolve

Tab Atkins Jr. wrote: (Fixing it does involve magic, or subclassing, but those are things that can be done internally, rather than exposed to authors as terrible API.) Could you say a bit more? Do you mean APIs that defensively "hand-box" so the user doesn't have to, with async map and its ove

Re: Promise.cast and Promise.resolve

Tab Atkins Jr. wrote: Note, though, that you can still have consensus*and* strong objections. Design-by-committee is still a failure mode to be avoided. Excellent point. Argues against "do both". Can't ditch .then/resolve given library code interop constraint. That forces the conclusion from

Re: async decision making (was Re: Promise.cast and Promise.resolve)

Alex Russell wrote: I'd rather we keep separate and conflict-prone APIs in separate objects, though. I'd rather we acknowledge that Promises are a library de-facto quasi-standard we are trying to codify, not green-field work where we can start over or "do both". Excited to hea

Re: async decision making (was Re: Promise.cast and Promise.resolve)

Edward O'Connor wrote: Perhaps TC39 should consider adopting a similar policy. Policy, schmolicy :-P. (Presumably clocks with deadlines are required; consensus could break afterwards, in spite of the formal rules.) Let's let our hair down a bit and get real here. We did not "declare consen

Re: Promise.cast and Promise.resolve

Sam Tobin-Hochstadt wrote: Just to be clear, that is not my recollection at all. For whatever the history is worth, this is also not my recollection of the consensus in May. Rashomon. Who is the Woodcutter? /be ___ es-discuss mailing list es-discu

Re: Promise.cast and Promise.resolve

Domenic Denicola wrote: The amount of heat Kevin has piled on to promises-unwrapping, repeatedly, has been puzzling and unwarranted, but I have chosen mostly to set it aside, as the words of someone who did not care to understand the whole history and design constraints involved in writing thi

Re: Promise.cast and Promise.resolve

Quildreen Motta wrote: but as with other parts of JavaScript, the simpler, orthogonal primitives are not available for users to derive more complex functionality from easily. So true. JS is like a mini-toolkit of three-tool Swiss Army Knife (functions) with constructor and closure tools as w

Re: Promise.cast and Promise.resolve

Paolo Amadini wrote: I think the conclusion of using two distinct objects for that (with the other named FuctionalPromise, Future, or anything else) resolves the issue. Imperative Promise implementations may use those alternative primitives internally. +1 /be __

Re: Promise.cast and Promise.resolve

Kevin Smith wrote: - Promise.cast is renamed to Promise.resolve (remove old Promise.resolve) - Keep then, reject chain (NOT DEFER, reject!) - Renaming .cast thus removes over-wrapping (always-wrap) deoptimization in old Promise.resolve So basically, since September, we've s

Re: Promise.cast and Promise.resolve

Ryan Scheel wrote: I do believe it meant to say 'cheap words and unreality'. Nothing to care about. Thanks -- makes me not care about replying, you are right! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/e

Re: Promise.cast and Promise.resolve

mfo...@eldergods.com wrote: > The existing promises library users would be faced with a porting problem > whose size is hard to estimate Naive go here; Promise.prototype.then= function(fn){ function recurse(val){ if(val.chain) val.chain(recurse)

Re: Promise.cast and Promise.resolve

Mark Roberts wrote: Wanting something value-ish, featureless, monadic, is a good goal for a differently named abstraction built on value objects. Promises are not that abstraction. Do the work to show the win, under a new name (Future?). I believe the win has already been shown

Re: Promise.cast and Promise.resolve

Brendan Eich <mailto:bren...@mozilla.com> February 4, 2014 at 7:46 PM Then you get a *plonk*, or at least a demeric, "demerit', of course. But I'm talking to a fake address. That's pretty bad, it makes me want to ignore you (*plonk* in USENET terms). Do better qu

Re: Promise.cast and Promise.resolve

mfo...@eldergods.com wrote: #3 is the only point I concede as being even possibly concrete Then you get a *plonk*, or at least a demeric, for ignoring the very concrete problem #2: combinators such as .all do not use .chain, they use .then. Also for ignoring #1 -- it doesn't matter that .then

Re: Promise.cast and Promise.resolve

Tab Atkins Jr. wrote: On Tue, Feb 4, 2014 at 10:55 AM, Rick Waldron wrote: > Per Resolution > (https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-30.md#conclusionresolution-3) > > - Promise.cast is renamed to Promise.resolve (remove old Promise.resolve) > - Keep then, rejec

Re: Should the default constructor return the return value of super?

We did discuss return expr; in constructors at the TC39 meeting, and my sense is that we want to keep that option. Classes as sugar (mostly), and all that. /be Claude Pache February 3, 2014 at 11:09 AM I don't see much advantage in being allowed to write `retu

Re: Import Expressions

Calvin Metcalf wrote: Yes The smell of expressions which evaluate depending on control flow not matching both branches preloading is enough that TC39 defers this and sticks to the ES6 grammar as proposed. We need to see enough clear use-cases where it wins to have import expressions, *and*

Re: Rename Number.prototype.clz to Math.clz

Qantas 94 Heavy wrote: Would Math.clz32 still throw a TypeError if the argument is not a number, nor an object with the [[NumberData]] internal slot? Currently all math functions perform ToNumber on their arguments, unlike what Number.prototype.clz is currently specified to do. ToUint32 does

Re: restrictions on let declarations

Thaddee Tyl wrote: By the way, even in the current specification of let, we can still construct a useless let: for (let x = 42;false;) console.log(x); (which is the same as the example you gave, using "if"). Yes, this falls out of the JS (and Dart, convergent evolution, coincidental as

Re: restrictions on let declarations

John Lenz wrote: I don't argue that it isn't a useless "let". I do point out that in "sloppy" mode, that other declaration are allow in practices by browsers. Chrome allows function, const, and var in the body of an if without block. But those aren't useless. They are quirky, but they do n

Re: restrictions on let declarations

John Barton wrote: Not silly. Can you suggest any on-line that most JS developers can understand discussing how these two forms differ? Here are some that describe them as equivalent: http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else http://msdn.microsoft.com/en-us/library/kw1tezhk(v

Re: restrictions on let declarations

Rick Waldron wrote: It is -- special forms that have heads can bind in bodies. We see this with formal parameters to functions, also with the defunct let blocks and let expressions of ES4. ML has similar forms. We made this block scoping, and how! Turns out Dart did the same.

Re: restrictions on let declarations

John Lenz wrote: How did "let x" in for-loops land: for (let x = 1; x < 10 ; i++) { // is "x" a fresh binding for every iteration? } This wouldn't be "block" scoping either. It is -- special forms that have heads can bind in bodies. We see this with formal parameters to functions, also wit

Re: restrictions on let declarations

John Lenz wrote: In my model if (y) let x = 42 is equivalent to if (y) { let x = 42 } and it is clear "x" in "alert(x)" is 0; It is as clear as those invisible braces in your model's input :-P. Come on, this is silly. "var" has quirks, but we are not propagating them to other forms, mak

Re: restrictions on let declarations

John Barton wrote: On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich <mailto:bren...@mozilla.com>> wrote: John Lenz wrote: Generally, I've always thought of: "if (x) ..." as equivalent to "if (x) { ... }" let and const (and class) are

Re: restrictions on let declarations

John Lenz wrote: Generally, I've always thought of: "if (x) ..." as equivalent to "if (x) { ... }" let and const (and class) are block-scoped. {...} in your "if (x) {...}" is a block. An unbraced consequent is not a block, and you can't have a "conditional let binding". The restriction avo

Re: Promise.cast and Promise.resolve

On Jan 28, 2014, at 10:14 PM, Kevin Smith wrote: >> >>> This seems like something that can be deferred to ES7. >> >> Which "this"? .chain is deferred to ES7, and in V8 experimentally. > > Deferring `chain` is, if not future-hostile to `chain`, then > "future-irritant". > > The way Promises

Re: Promise.cast and Promise.resolve

Ryan Scheel wrote: This seems like something that can be deferred to ES7. Which "this"? .chain is deferred to ES7, and in V8 experimentally. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promise.cast and Promise.resolve

Kris Kowal wrote: I would pick "Promise.cast" and "then", let complexity melt off the spec, and stop worrying. Seems not everyone agrees, especially since Promise.resolve is all over the place. I wonder with task.js like solutions whether we'll actually have lots of hand-.then'ing of promis

Re: Promise.cast and Promise.resolve

Quildreen Motta wrote: I suppose using names that don't give you a hint of the meaning of the operation fits perfectly Haskell's (and Scalaz's) "Avoid Success At All Costs" tradition lulz. And so we will go with 'chain'. /be ___ es-discuss mailing

Re: Promise.cast and Promise.resolve

Andreas Rossberg wrote: Seriously, Haskell calls it>>=. Right, that thing. Did it have the f-l-a-t-... name in Haskell, or is it pronounced b-i-n-d always, monads or not? (It also has concatMap, which is just the same function restricted to lists.) Rhyming. /be

Re: Promise.cast and Promise.resolve

Andreas Rossberg wrote: On 29 January 2014 00:30, Brendan Eich wrote: > Andreas Rossberg wrote: >>> >>> `flatMap` >>> ... >> >> >> The V8 implementation provides it under the name `chain', with the >> obvious semantics. &g

Re: Promise.cast and Promise.resolve

Andreas Rossberg wrote: `flatMap` ... The V8 implementation provides it under the name `chain', with the obvious semantics. +1 on chain as name, not flatMap, but Haskell'ers should weigh in. Wait, no. :-P /be ___ es-discuss mailing list es-discus

Re: Rename Number.prototype.clz to Math.clz

Luke Wagner wrote: It seems to me that we*must* have Math.clz perform ToUint32() on its input. Otherwise (if ToInt32() is used), even if the expression is written "Math.clz(x>>> 0)", asm.js/type-inference won't be able to optimize away the<0 branch since the ToInt32() in the semantics of Ma

Re: Promise.cast and Promise.resolve

Domenic Denicola wrote: From: es-discuss on behalf of Brendan Eich > Quildreen Motta wrote: >> If that's correct, I don't see any use cases for Promise.resolve right now, unless a library where to provide a corresponding unspecified `flatMap` implementation. >

Re: Promise.cast and Promise.resolve

Quildreen Motta wrote: If that's correct, I don't see any use cases for Promise.resolve right now, unless a library where to provide a corresponding unspecified `flatMap` implementation. IIRC (and I may not; endless promises threads make me sleepy) this is the reason to have Promise.resolve:

Re: detecting JS language mode for tools

Erik Arvidsson wrote: Note no "module" form in ES6. module M from './path/to/module'; is a valid ModuleItem. Ah, right. I thought John meant module M {...}. Thanks! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.o

Re: detecting JS language mode for tools

John Lenz wrote: There are three issues in my mind for tooling: 1) should the code be parsed as "use strict" 2) are "import" and "export" and "module" statements valid Note no "module" form in ES6. 3) should top level declarations be considered visible outside the file (no can be inferred fr

Re: detecting JS language mode for tools

Domenic Denicola wrote: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich > Examples? What is the specified grammar? > From [the HTML spec][1]: > The `type` attribute gives the language of the script or format of the data. If the attribute i

Re: detecting JS language mode for tools

On Jan 27, 2014, at 8:35 PM, Erik Arvidsson wrote: > > All browsers support non media types. Can we change the specs to match reality Examples? What is the specified grammar? I hope you aren't thinking of language= here. How about fallback for old browsers? /be ___

Re: detecting JS language mode for tools

John Barton wrote: Why can't

Re: detecting JS language mode for tools

Kevin Smith wrote: Because it is js everywhere. Pick any file in an AMD/require.js system and you can parse it. ES6 cannot support require as a function that synchronously loads from the filesystem, and I think you know this. Without a new extension, you cannot "impo

Re: ES6 timetable and current status

Allen Wirfs-Brock wrote: The harmony proposals and old ES6 strawman wiki pages are generally not being actively maintained. Any already in ES6 should be prefaced by a pointer to the spec draft. rwaldron helps with this, it is a duty we share as wiki curators, and it's easy to edit. Copy from

Re: detecting JS language mode for tools

John Barton wrote: On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich <mailto:bren...@mozilla.com>> wrote: John Barton wrote: It's pretty clear from NPM experience that a new suffix is not needed for out-of-line modules. Or are you suggesting that

Re: detecting JS language mode for tools

John Barton wrote: It's pretty clear from NPM experience that a new suffix is not needed for out-of-line modules. Or are you suggesting that Node.js lacks tooling? I'm not offended, just trying to understand. What about the node experience helps? They have only one type of input,

Re: detecting JS language mode for tools

Brendan Eich wrote: OK, sorry I jumped in the middle of things missing some context. In fact, I think what we've been planning on proposing is not too far -- I think -- from what you're talking about. The plan is *not* a module attribute (that was a think-o on my part, and

Re: detecting JS language mode for tools

John Lenz wrote: 1. a file extension Talk here is not demand, and I bet we'll regret trying to add a new one. Extensions mapped by servers to media types require server configury, often missed or mangled. This has led in the past to clients hardcoding, e.g. text/javasc

Re: Reason why generators do not have references to themselves?

Bradley Meck wrote: Unsure on how new syntax features like await should deal w/ multiple operands though, like if await wanted to turn multiple promises into an array. Comma operator takes comma separated list out of the equation. No one proposed this. Do you have a use-case? Task.js and other

Re: Proposal: Generator returning a value should throw SyntaxError

David Herman wrote: Finally, task.js is just an example of building a control abstraction out of iterators. It happens that the for-of control flow form is imperative and doesn't have a use for a return value. That doesn't mean other control flow operations won't. +1. The need for an afforda

Re: detecting JS language mode for tools

also allows you to control for when the scripts resource is there, in particular to be sure that necessary bootstrapping/kernel code has loaded before you need to do some wiring up of your app. But it's not even worth overthinking. It's so obviously, obscenely anti-usable not t

Re: detecting JS language mode for tools

Kevin Smith wrote: Is a new attribute necessary? What about using @type? Old browsers will ignore unknown types, losing the two-way fallback option. Two-way fallback? Why is that important? Since modules are implicitly strict, there is little intersection between scripts

Re: detecting JS language mode for tools

David Sheets wrote: There is no out-of-band metadata in a new script attribute. Attributes are > data, not data-about-data, and in-band in HTML. The channel is the contents of the script element or the ES resource. The attribute is not transmitted in the contents of the script element or ES re

Re: detecting JS language mode for tools

David Sheets wrote: On Sat, Jan 25, 2014 at 11:26 PM, Brendan Eich wrote: > David Sheets wrote: >>> >>> . Old browsers ignore the new attribute will process the content, which >>> >could be written to work "both ways". >> >> &

Re: detecting JS language mode for tools

John Barton wrote: The Script goal disallows 'import' and 'export' specifically to ensure that the Script goal is inconvenient for developers and thus they are encouraged to shift to the Module goal. No, that's not the rationale. The reason is to avoid enabling more synchronous

Re: detecting JS language mode for tools

Peter van der Zee wrote: `` Again, no two-way fallback option. Clever thought re: implicit CDATA content model, though! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: detecting JS language mode for tools

David Sheets wrote: . Old browsers ignore the new attribute will process the content, which > could be written to work "both ways". Is a new attribute necessary? What about using @type? Old browsers will ignore unknown types, losing the two-way fallback option. /be _

Re: Fwd: Reason why generators do not have references to themselves?

[replying to a message you sent off-list, hope it is ok. /be] Brendan Eich wrote: Bradley Meck wrote: Perhaps, but I am still a bit concerned functionality wise that I do not have a clean way to force the `new generator()` piece of code to be inside of the generator. I think you've

Re: transpiling ES6 generator functions to ES5: what next?

David Bruant wrote: Hi Ben, Sorry for the very late response. This is quite an interesting work, thanks for sharing! I'm particularly interested in your test suite [1] which is impressive. This is making me realize that generators are fully compilable (efficiently from what I can see) into ES5

Re: detecting JS language mode for tools

John Barton wrote: On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock mailto:al...@wirfs-brock.com>> wrote: I should have also included: 2A) Hopefully, overtime, the old script syntactic goal will fade from use, and the module goal will become the norm for new code. Now here is

Re: Fwd: Reason why generators do not have references to themselves?

Bradley Meck wrote: Perhaps, but I am still a bit concerned functionality wise that I do not have a clean way to force the `new generator()` piece of code to be inside of the generator. I think you've gone down a bad path. Even without task.js, couldn't you put the promises .then'ing in the g

Re: Reason why generators do not have references to themselves?

Domenic Denicola wrote: Task.js is still on "JavaScript1.8," and is not ES6-compatible. It won't work with modern browsers, or with Regenerator. Fork and fix, should be easy. I expect a PR would be accepted in due course. SpiderMonkey seems to have ES6 generator support somewhat there (than

Re: Fwd: Reason why generators do not have references to themselves?

Bradley Meck wrote: Is that true even though then should fire after the generator unwinds its stack? True if .then always runs in a later turn -- sorry. Still, my point stands: you are not using task.js-like scheduler/combinator approach for an apples-to-apples comparison with await. If you

<    2   3   4   5   6   7   8   9   10   11   >