I'd just like to express my enthusiasm for taking a formal approach to the
kernel language. For everything outside the kernel, defining it by
self-hosting, by a meta-circular interpreter (where the interpreter is
written only in the kernel subset of the language) or by desugaring is fine.
These
On Thu, May 20, 2010 at 8:49 AM, Mark S. Miller erig...@google.com wrote:
I'd just like to express my enthusiasm for taking a formal approach to the
kernel language. For everything outside the kernel, defining it by
self-hosting, by a meta-circular interpreter (where the interpreter is
There is another approach to using JavaScript to specify JavaScript that we
have discussed within TC39. The idea to use the exact same style of
specification as current used for ES5 but to use JavaScript as the meta
language rather than pseudo-code.
Because this work is relevant to this
I'd just like to express my enthusiasm for taking a formal approach to the
kernel language. For everything outside the kernel, defining it by
self-hosting, by a meta-circular interpreter (where the interpreter is
written only in the kernel subset of the language) or by desugaring is fine.
Hi Mike, sorry I overlooked this message.
| This allows cyclic dependencies between any two modules
| in a single scope
1) Is this to say that cycles are allowed, or not allowed, in
other scenarios? (f ex remote or filesystem-loaded modules)
It's an automatic consequence of lexical
Heh-- excuse my bogus BNF! That's just a made-up extension that allows 1 or
more instances of MRL, separated by the ',' token. Spelled out:
MRL+(',') ::= MRL
| MRL+(',') ',' MRL
PS If this is still unclear, just replace MRL+(',') with MRLList, and add the
production:
Hi,
Sorry if my question is stupid or does not really belongs here. I will be
thankful to get some clarification on es specs since I just discovered that
my interpretation of how getter / setters are supposed to behave appears to
be different from the behavior in observed in modern browsers.
var
On May 20, 2010, at 11:37 AM, Irakli Gozalishvili wrote:
Hi,
Sorry if my question is stupid or does not really belongs here. I will be
thankful to get some clarification on es specs since I just discovered that
my interpretation of how getter / setters are supposed to behave appears to
The relevant portion seems to be
11.13.1 Simple Assignment ( = )
The production AssignmentExpression : LeftHandSideExpression =
AssignmentExpression is evaluated as follows:
1. Let lref be the result of evaluating LeftHandSideExpression.
2. Let rref be the result of evaluating
On May 20, 2010, at 11:37 AM, Irakli Gozalishvili wrote:
Hi,
Sorry if my question is stupid or does not really belongs here. I
will be thankful to get some clarification on es specs since I just
discovered that my interpretation of how getter / setters are
supposed to behave appears to
So for a non host object o,
o.x = o.x - 1
should yield a number regardless of the details of any setter for x on
o, assuming o is not frozen and said setter returns normally.
The assignment operator is defined in the language fairly clearly in a way that
means that the behaviour is
On May 20, 2010, at 11:47 AM, Brendan Eich wrote:
I am also afraid that this might break some of the frameworks in
rare cases like in this example above. (a = b = c is commonly used
syntax)
No browser does what we used to do, so any framework counting on
setters
2010/5/20 Oliver Hunt oli...@apple.com:
So for a non host object o,
o.x = o.x - 1
should yield a number regardless of the details of any setter for x on
o, assuming o is not frozen and said setter returns normally.
The assignment operator is defined in the language fairly clearly in a way
Thanks to everyone for a good explanation, as I was assuming my expectations
were wrong, guess partially, because of the SpiderMonkey's behavior in past
(Thanks Brendan for clearing this up, I was pretty sure that was the
behavior in xulrunner, apparently it's in past now :).
--
Irakli
On Thu, May 20, 2010 at 9:11 AM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
There is another approach to using JavaScript to specify JavaScript that we
have discussed within TC39. The idea to use the exact same style of
specification as current used for ES5 but to use
Thanks for the detailed explanations, David. Here's a few follow-
up questions (with done questions snipped out):
David Herman wrote:
| This allows cyclic dependencies between any two modules
| in a single scope
1) Is this to say that cycles are allowed, or not allowed, in
other
It's just a document copyrighted by ecma that happens to mostly be code and is
largely derivate from the ES5 spec. which is also copyrighted by Ecma.
Paranoia about reading it is a matter between you and your lawyers.
Allen
From: Mark S. Miller [mailto:erig...@google.com]
Sent: Thursday, May
On Thu, May 20, 2010 at 3:47 PM, Mike Wilson mike...@hotmail.com wrote:
Thanks for the detailed explanations, David. Here's a few follow-
up questions (with done questions snipped out):
Thanks for all your detailed feedback!
David Herman wrote:
| This allows cyclic dependencies between any
I wrote:
As you know, I have avoided looking at this until the IPR situation was
straightened out. Since it now seems to be, could you (or someone
representing Ecma) repost this with a BSD license?
On Thu, May 20, 2010 at 2:08 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Having unspecified endianness in the specification of TypedArrays seems like a
show-stopper to me. There are two alternatives here:
- If you do any I/O, you want the endianness to be specified. Sending data
from one process to another with a different endianness would get you into
trouble.
2010/5/20 ๏̯͡๏ Jasvir Nagra jas...@gmail.com:
The other is to limit the scope from which the imported modules imports get
selected to the current scope:
module Fribble {}
module Foo {
module JQ = load 'http://';
module Drawing = load 'http://.../gun.js';
module A = load
21 matches
Mail list logo
