Re: Chained comparisons from Python and CoffeeScript
On Tue, Jul 23, 2013 at 7:52 PM, Brendan Eich bren...@mozilla.com wrote: Andy Earnshaw wrote: On Mon, Jul 22, 2013 at 9:08 PM, Brendan Eich bren...@mozilla.commailto: bren...@mozilla.com wrote: Opt-in sounds like a better solution, if pragmas are to be entered into the specification then it could even become part of use strict; Your point applies here too, though. use strict; (did you forget the quotes) has meaning in ES5, no meaning before, and therefore not likely new meaning after ES5. I didn't forget the quotes :-) I remembered reading the proposal at harmony:pragmas, but I didn't check the harmony:proposals page to see what its fate had been. I was thinking that an ES6 use strict wouldn't need to retain compatibility with ES5 because of the differing syntax. Even still, you raise a good point, changing the meaning for ES6 might have been confusing. Did you mean to reply-all? Just checking. Oops. Still not used to replying to mailing lists. I did this a couple of times on other threads and didn't realise why everyone was saying almost the exact same things I said as if I'd not said them! We do not plan to evolve use strict. Nor do we plan to remove the quotes (we've considered that at http://wiki.ecmascript.org/**doku.php?id=harmony:pragmashttp://wiki.ecmascript.org/doku.php?id=harmony:pragmas, deferred from http://wiki.ecmascript.org/**doku.php?id=harmony:proposalshttp://wiki.ecmascript.org/doku.php?id=harmony:proposals-- note strikethrough). It's possible more pseudo-pragmas in quotes may be standardized but as noted: wicked fight, requiring lots of data and careful argumentation. I would really like to see this; the one-time evaluation of each operand could eliminate the need for temporary variables and the shorter, more readable code just sweetens the deal. However, I think if we're going to introduce more pseudo-pragmas, they should probably provide a significant change like Claude indicated, fixing typeof null and several other improvements (although I'm not sure I agree with all his ideas for a perfect language ;-)). I think he was making the point that perfect is not an option (I am able to make coffee from within my preferred browser). We almost certainly are not going to fork the language with a pragma, but if we do it will be new syntax, to choke old browsers. Otherwise the testing burden doubles (again; this happened with use strict; in ES5 due to its runtime semantic changes). Yeah, I suppose it's not such a good idea forking the language at all. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
use strict 2
I think that we can provide a more strict mode to deal with some long-lasting
defects. In more strict mode,
Implicit type conversion is disabled.Functions declarations are disabled. All
`function(){}` are considered function literal expression.Statement labels are
disabled or strictly restricted.A `break` statement or a fallthrough
declaration is required to be added into the branches inside a switch
statement.`eval` is disabled. ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use strict 2
2013/7/24 BelleveInvis infinte.c...@hotmail.com I think that we can provide a more strict mode to deal with some long-lasting defects. In more strict mode, Why? Who does this benefit? You provide 5 rules. What ties them together? Why not other rules? What would be the benefit of this new mode over additional *external* tooling (like TypeScript or JSLint/JSHint/ESLint, etc.)? Be aware that TC39 seems to currently agree on the 1JS idea which is pretty much not adding any new modes anymore. So you'll need to make a very strong case to change their mind :-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict 2
I consider your first three complaints as features instead of defects, and the
last one as an expert feature. The use strict directive corrected only
objectively problematic misfeatures.
??Claude
Le 24 juil. 2013 ?? 11:35, BelleveInvis infinte.c...@hotmail.com a ??crit :
I think that we can provide a more strict mode to deal with some
long-lasting defects. In more strict mode,
Implicit type conversion is disabled.
Functions declarations are disabled. All `function(){}` are considered
function literal expression.
Statement labels are disabled or strictly restricted.
A `break` statement or a fallthrough declaration is required to be added
into the branches inside a switch statement.
`eval` is disabled.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use strict 2
BelleveInvis wrote:
I think that we can provide a more strict mode to deal with some
long-lasting defects. In more strict mode,
* Implicit type conversion is disabled.
* Functions declarations are disabled. All `function(){}` are
considered function literal expression.
This in particular is a private fetish -- whatever floats your boat, but
nothing to put in the standard.
Function hoisting as a simplified letrec and to enable top-down program
source decomposition is a feature.
/be
* Statement labels are disabled or strictly restricted.
* A `break` statement or a fallthrough declaration is required to
be added into the branches inside a switch statement.
* `eval` is disabled.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Andy Earnshaw wrote: On Tue, Jul 23, 2013 at 7:52 PM, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: We almost certainly are not going to fork the language with a pragma, but if we do it will be new syntax, to choke old browsers. Otherwise the testing burden doubles (again; this happened with use strict; in ES5 due to its runtime semantic changes). Yeah, I suppose it's not such a good idea forking the language at all. The slow-mo, evolutionary web way: extend to provide coexisting new and old features, and deprecate the old. They fade away, leaving vestigial organs that might fade over time (or might be misunderstood and still be used somehow). This ups the ante for linters, nearly-same-semantics compile-to-JS languages, and evolving JS as a compiler target to keep other languages nearly-same-semantics. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Chained comparisons from Python and CoffeeScript
Perhaps there should be a spec somewhere for misfeatures like `a b c` which linters ought to all reject. It could then only include things that (if we could turn back time) we probably would've liked to see in 'strict mode', but can't because that ship sailed. If certain features were always regarded as errors by linters, that would certainly discourage their use. The next step would be making chrome dev tools have a built in linter that warns about these pseuso-errors/spec-mistakes. Maybe if that goes well we'll be able to introduce the new semantics in 5 years time. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
2013/7/24 Forbes Lindesay for...@lindesay.co.uk Perhaps there should be a spec somewhere for misfeatures like `a b c` which linters ought to all reject. It could then only include things that (if we could turn back time) we probably would've liked to see in 'strict mode', but can't because that ship sailed. David Bruant set up a repo to collect these: https://github.com/DavidBruant/ECMAScript-regrets I don't think anyone wants to invest the time to create an actual spec for ES5 \ misfeatures, but collecting them and learning from them is probably the next best thing. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Chained comparisons from Python and CoffeeScript
Too much blank-slate-ism here for me. ES5 strict was not the opportunity: 1. The clock would have to go back much farther if people actually wrote a b c, but we still lack evidence that this is much used. It *could* be, so we're loath to change its semantics incompatibly (and we won't want opt-in versioning, or modes)... 2. Just deprecating is not enough, especially if the feared misfeature from C via Java is not actually misused. We'd want to obsolete, to clear the decks for Pythonic chaining. But that is not in the cards (see 1). /be Tom Van Cutsem wrote: 2013/7/24 Forbes Lindesay for...@lindesay.co.uk mailto:for...@lindesay.co.uk Perhaps there should be a spec somewhere for misfeatures like `a b c` which linters ought to all reject. It could then only include things that (if we could turn back time) we probably would've liked to see in 'strict mode', but can't because that ship sailed. David Bruant set up a repo to collect these: https://github.com/DavidBruant/ECMAScript-regrets I don't think anyone wants to invest the time to create an actual spec for ES5 \ misfeatures, but collecting them and learning from them is probably the next best thing. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let this object of global environment be specified by host
is this out of another discussion or it's me not understanding the context, the what, the where, and the why about such topic? Thanks for any clarification On Wed, Jul 24, 2013 at 8:11 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently HTML overrides the ES standard here to set the this object to WindowProxy (whereas Window is the global). The ES standard should just let the host decide how this is set up. No need for conflicts here. (Solving this (no pun...) leaves us with document.all I think. Don't have ideas for that one.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Let this object of global environment be specified by host
We have worked on this, since even if the embedding makes the global object up, it must satisfy certain observable spec requirements (to do with var, prototype properties, etc.). https://bugs.ecmascript.org/show_bug.cgi?id=78 http://wiki.ecmascript.org/doku.php?id=harmony:multiple_globals etc. /be Anne van Kesteren wrote: Currently HTML overrides the ES standard here to set the this object to WindowProxy (whereas Window is the global). The ES standard should just let the host decide how this is set up. No need for conflicts here. (Solving this (no pun...) leaves us with document.all I think. Don't have ideas for that one.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
HTML version of the ES6 draft
Any chance we can get an official HTML version of the draft specs? This is out of date: http://people.mozilla.org/~jorendorff/es6-draft.html It is nice to be able to link to parts of the spec, etc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: HTML version of the ES6 draft
I was on vacation. I'll post an updated version this week. (I would have done it already this morning, but the Word document has new numbering, so I need to do some fixups.) -j On Wed, Jul 24, 2013 at 11:46 AM, John Lenz concavel...@gmail.com wrote: Any chance we can get an official HTML version of the draft specs? This is out of date: http://people.mozilla.org/~jorendorff/es6-draft.html It is nice to be able to link to parts of the spec, etc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Is it really a good idea for octal numbers to allow capital-O, e.g. 0O755?
The decision of record, including a rationale citing lack of control over lookalikes https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html Rick On Tue, Jul 23, 2013 at 11:45 PM, Brendan Eich bren...@mozilla.com wrote: Claude Pache wrote: the risk of eye-bleeding is low. My eye already bled just from this thread! http://cheezburger.com/**2253407488 http://cheezburger.com/2253407488 /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Extractors for destructing assignment and pattern matching
I am wondering that whether the current draft have something similar to Scala's
extractors, which could be used in pattern matching.
For example, this pattern:
Email(username, host) = ooxx
is defined as
{let results = Email.unapply(ooxx, 2)if(results !==
undefined) [username, host] = resultselse throw new MisMatchError}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Let this object of global environment be specified by host
On Wed, Jul 24, 2013 at 9:37 AM, Brendan Eich bren...@mozilla.com wrote: We have worked on this, since even if the embedding makes the global object up, it must satisfy certain observable spec requirements (to do with var, prototype properties, etc.). https://bugs.ecmascript.org/show_bug.cgi?id=78 http://wiki.ecmascript.org/doku.php?id=harmony:multiple_globals etc. That looks good. I got the impression from a discussion with Allen/Luke that specifying this was not yet considered and based on that Allen asked for this email. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
And why not? Because yield is a statement
Yield is an expression.
Thanks for the correction. Yes, yield expr is an expression, syntactically.
It doesn't have the nice composition and code transformation properties
that I usually associate with expressions, it imposes unusual restrictions
on its *context* and impedes functional abstraction:
1 though yield constructs expressions from expressions, it isn't a
function (can't pass yield around or store it in a variable), nor is
yield expr a function call.
2 1 can be worked around, but not with the usual tools of function
definitions and calls - yield forces use of function* and yield*
for abstracting over expressions containing it.
3 yield is disappointingly similar to this, in being implicitly bound to
the next function* (function, for this). Expressions referencing
either this or yield cannot be wrapped in functions (btw, can
generator bodies reference an outer this?), because this would
cut the implicit binding.
For this, workarounds include arrow functions or bind, for yield,
the only workaround is yield*+function* (or diving even deeper,
with hand-written iterators). Having to use different function
mechanisms for the latter is by design, so it is a workaround only
from the perspective of wanting to use uniform tools for functional
abstraction.
For instance, we cannot write
function* g() { (function(){ yield 1 })() }
function* g() { function y(x){ yield x } y(1) }
but have to write
function* g() { yield* (function*(){ yield 1 })() }
function* g() { function* y(x){ yield x } yield* y(1) }
and when I try to write a polyfill for for-of, I end up with two partial
fills (neither models early return):
function forof(g,cb) { // non-generator callbacks only
var r;
while(true) {
r = g.next();
if (r.done) break; // skip return value?
cb(r.value);
}
}
function* forofG(g,cb) { // generator callbacks only
var r;
while(true) {
r = g.next();
if (r.done) break; // skip return value?
yield* cb(r.value);
}
}
We could switch on the type of cb, and go down to handwritten iteration,
to unify the two partials into one, but then we'd still have to cope with
different usage patterns at the call sites (call with function vs. yield*
with function*).
Why shouldn't I be able to traverse an array, using the ES5 standard
operations for doing so, yielding intermediate results from the
traversal (recall also that yield can return data sent in via .next,
for incorporation into such traversals)?
You certainly can, with one modification: using *ES6* standard
operations (external iterators vs the ES5 forEach internal iterator).
Generators and non-generator iterators and for-of and comprehensions
hang together really nicely in practice.
function* g(){
for(x of [1,2,3]) yield transform(x);
}
You're suggesting to abandon ES5 array iteration patterns in favor
of more general ES6 iterator patterns. That would be okay (*), but
1 it leaves fairly new (ES5) API surface as legacy
2 generators do not compose as freely as iteration functions,
because they are tied to special syntax and restricted contexts
(*) if we want to go down that route, then why join TypedArrays
with Arrays, according to old-style iteration-API? Shouldn't both
be covered by a common iterator-based API instead?
Hand-written iterators don't suffer from 2, but are somewhat awkward
to write in place, and expose their lower-level protocol. Perhaps the
solution is a rich enough standard iterator library, with generators as
local glue and iterator library functions for supporting more general
functional abstraction and composition.
Perhaps we need to play a bit more with such iterator library functions,
to get a better feeling for the limitations imposed by generators, and to
give my concerns a concrete form?
I've put up a gist with a few obvious things I'd want to have (something
like zip and feed should really be standard; the former often has
syntax support in the form of parallel comprehensions, the latter is
needed if we want to use an input-dependent generator in a for-of):
https://gist.github.com/clausreinke/6073990
and there are several things I don't like, even at this simple stage:
- if you compare the versions that use for-of with those (ending
with a _) that use a user-defined abstraction forofG, you'll see
a lot of syntax noise, even worse than with the old long-hand
function - in terms of making functional abstraction readable,
this is going in the wrong direction, opposite to arrow functions.
- I haven't yet figured out how to end an outer generator early
from within a yield* nested one (as needed for take_), without
replacing yield* with a micro-interpreter. That might just be
my incomplete reading of the draft spec, though?
Methods can be replaced by
Re: generators vs forEach
Claus Reinke wrote:
And why not? Because yield is a statement
Yield is an expression.
Thanks for the correction. Yes, yield expr is an expression,
syntactically.
It doesn't have the nice composition and code transformation
properties that I usually associate with expressions, it imposes
unusual restrictions
on its *context* and impedes functional abstraction:
1 though yield constructs expressions from expressions, it isn't a
function (can't pass yield around or store it in a variable), nor is
yield expr a function call.
Same for every other operator.
2 1 can be worked around, but not with the usual tools of function
definitions and calls - yield forces use of function* and yield*
for abstracting over expressions containing it.
So does 'return' and this is for a good reason: we are not adding deep
continuations (as discussed up-thread).
3 yield is disappointingly similar to this, in being implicitly
bound to
the next function* (function, for this). Expressions
referencingeither this or yield cannot be wrapped in functions
(btw, cangenerator bodies reference an outer this?), because
this would
cut the implicit binding.
No binding in the common sense of that word.
Again: same as 'return'.
For this, workarounds include arrow functions or bind, for
yield,the only workaround is yield*+function* (or diving
even deeper,
with hand-written iterators).
This rehashes a pointless lament that we don't have deep continuations.
Having to use different functionmechanisms for the latter is by
design, so it is a workaround onlyfrom the perspective of wanting
to use uniform tools for functionalabstraction.
For instance, we cannot write
function* g() { (function(){ yield 1 })() }
function* g() { function y(x){ yield x } y(1) }
but have to write
function* g() { yield* (function*(){ yield 1 })() }
function* g() { function* y(x){ yield x } yield* y(1) }
Same as 'return'.
We discussed escape continuations:
http://wiki.ecmascript.org/doku.php?id=strawman:return_to_label
This strawman is not on any roadmap. It did not fare well in past TC39
meetings and discussions.
and when I try to write a polyfill for for-of,
Don't do that!
New special forms require compilers.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
