On 10 Dec 2013, at 01:32, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Stylistic issues
Well, for 4627bis, we have tools that allowed us to fuzz the ABNF against a set
of existing JSON implementations.
This is the kind of care I expect from spec writers.
Nobody has fessed up to having done
Thank you, for making it clear :-)
On Tue, Dec 10, 2013 at 5:03 AM, Brendan Eich bren...@mozilla.com wrote:
Hemanth H.M wrote:
Can this be a pattern in itself or is there any specific name for this
paradigm ?
Python folks call it coroutines but it's not the canonical meaning of
that
On Tue, Dec 10, 2013 at 4:12 PM, Carsten Bormann c...@tzi.org wrote:
So a JSON infoset would capture a processed AST, but not yet the
transformation to the data model level.
JSON implementations would create the JSON data model from that infoset
(typically without actually reifying the latter
On 10 Dec 2013, at 07:52, James Clark j...@jclark.com wrote:
Most users of XML deal with higher-level semantic abstractions rather than
directly with the XML Infoset, but it has proven very useful to be able to
specify these higher-level semantic abstractions in terms of the XML Infoset
On 10 Dec 2013, at 12:39, James Clark j...@jclark.com wrote:
The only thing that makes me hesitate is that I could imagine implementations
that distinguish integers and floats, and use C-style rules to distinguish
the two. For example, 1 is an integer but 1.0 or 1e0 is a float. I don't know
From http://ecma-international.org/ecma-262/5.1/#sec-15.3.4.3 and
http://ecma-international.org/ecma-262/5.1/#sec-15.3.4.4:
The `thisArg` value is passed without modification as the `this` value. This
is a change from Edition 3, where a `undefined` or `null` `thisArg` is
replaced with the
Le 10 déc. 2013 à 13:59, Mathias Bynens math...@qiwi.be a écrit :
From http://ecma-international.org/ecma-262/5.1/#sec-15.3.4.3 and
http://ecma-international.org/ecma-262/5.1/#sec-15.3.4.4:
The `thisArg` value is passed without modification as the `this` value. This
is a change from
Turns out this is a bug in the spec:
https://bugs.ecmascript.org/show_bug.cgi?id=2370
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Dec 10, 2013, at 5:32 AM, Mathias Bynens wrote:
Turns out this is a bug in the spec:
https://bugs.ecmascript.org/show_bug.cgi?id=2370
I'll respond further when i deal with the actual bug report , but for now, I'm
not sure I agree with your conclusion.
What you have been talking about
new Function is simply calling a constructor - the fact that it creates a
callable object is irrelevant as there is nothing magical about the constructor
itself.
The new function object itself is also scoped to the root lexical environment,
not the strict mode function it is being called from,
Brendan Eich wrote:
Brendan Eich wrote:
How about something like this?
spawn(function *() {
var gen = this.thread;
stream.on('data', function (data) {
gen.send(data);
});
console.log(yield gen.next());
});
Sorry, a generator instance can't next itself, so that
I was **NOT** complaining about that and I know the behavior ... those
double quotes were not there by accident.
de-stricter ^_^
was to point out that even inside a strict part of the code you can execute
runtime out of strict code ... code so mine was a hint: if you don't use
strict because you
[ reposting, since there was no reply to original posting ]
[ thread starting here:
https://mail.mozilla.org/pipermail/es-discuss/2013-August/033089.html ]
Allen Wirfs-Brock wrote:
An interesting proposal, but I'm not yet sold. Here are some of the
issue I see:
1) By newing a function an
FWIW, function [A-Za-z_] includes `var expr = function expr() {}` or
`{expr: function expr(){}}` both quite common patterns (the first one when
you want to be able to debug the name of the function but due inline, later
on, features detection, the former might change)
Still I agree with David and
On Dec 10, 2013, at 10:18 AM, Brendan Eich wrote:
Yield (after return, but return is a statement form, of course -- yield is an
expression form due to send) can have an operand on its right, or no operand
(meaning yield undefined). Cc'ing Allen to double-check that the spec will
say so.
On Sunday, December 8, 2013, Hemanth H.M wrote:
Ah! Sweet :)
Makes sense of why send() method was implemented for generators.
send(value) was removed in favor of next(value)
Rick
Can this be a pattern in itself or is there any specific name for this
paradigm ?
On Sun, Dec 8, 2013 at
* Allen Wirfs-Brock wrote:
On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:
If TC39 said ECMA-404 is going to be replaced by a verbatim copy of the
ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no other
discussion of JSON and a clear indication that future editions will not
I didn't ask for anything indeed, I was rather pointing out your RegExp
search was not so accurate. The rest, once again, I agree with David,
rationales or not.
On Tue, Dec 10, 2013 at 1:55 PM, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
FWIW, function [A-Za-z_] includes
Peter,
I would be idea if you registered submitted these issues to bugs.ecmascrip.org
as tickets against ECMA-404. That way you would be copied on any discussion
regarding them that took place via the bug tracking systems.
Regardless, I'll make some preliminary responses below.
Allen
On Dec
On Dec 9, 2013, at 10:52 PM, James Clark wrote:
On Fri, Dec 6, 2013 at 2:51 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The static semantics of a language are a set of rules that further restrict
which sequences of symbols form valid statements within the language. For
On Dec 10, 2013, at 2:08 AM, Martin J. Dürst wrote:
On 2013/12/10 9:32, Allen Wirfs-Brock wrote:
...
Specs. can have both technical and editorial bugs. If you think there are
bugs in ECMA-404 the best thing to do is to submit a bug ticket at
bugs.ecmascript.org. If there is a
On Dec 10, 2013, at 3:08 PM, Bjoern Hoehrmann wrote:
* Allen Wirfs-Brock wrote:
On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:
If TC39 said ECMA-404 is going to be replaced by a verbatim copy of the
ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no other
discussion of
(important typo correction in last paragraph)
On Dec 10, 2013, at 3:08 PM, Bjoern Hoehrmann wrote:
* Allen Wirfs-Brock wrote:
On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:
If TC39 said ECMA-404 is going to be replaced by a verbatim copy of the
ABNF grammar in
All ECMAScript objects have a toLocaleString method, originally defined in
Object.prototype and overridden in Array, Number, and Date. The parameter list
of this method has changed over time:
- In ES3 and ES5, the methods don't take parameters, but there's a note The
first parameter to this
OK this was rough/quick malformed answer ... just realizing it!
Overall, I wasn't complaining about fat arrow and I understand it made
through ES6, I just honestly still don't quite get it, and probably ever
will, but it was my fault to bring it back as off-topic matter for this
thread.
FWIWI, toString, as well as toLocaleString in the Object.prototype, has
been used as a hack to bring non-enumerable properties in Internet Explorer
8 and lower.
I am not sure what will be, but if anything to not break the web, should
consider this fact, even if not concerned as I am about IE8
On Dec 10, 2013, at 9:28 PM, James Clark wrote:
On Wed, Dec 11, 2013 at 11:59 AM, R S say...@gmail.com wrote:
On Tue, Dec 10, 2013 at 8:44 PM, James Clark j...@jclark.com wrote:
For example, the ECMA spec needs the order of key/value pairs in an object to
be significant
I don't think
27 matches
Mail list logo
