Re: Comments on Refutable Patterns proposal
Brandon Benvie wrote:
On 3/21/2013 10:54 AM, Tab Atkins Jr. wrote:
On Thu, Mar 21, 2013 at 10:51 AM, Brandon Benvie
bben...@mozilla.com wrote:
On 3/21/2013 10:14 AM, Axel Rauschmayer wrote:
And with rest patterns at the end only, I don't think you'd ever want
to write ... without a subpattern. The only difference between [x,
y] and [x, y, ...] would be that the latter (somewhat redundantly)
checks the presence of a length property.
Ah! I would expect [x,y] to only match arrays whose length is 2. Is
there a
benefit to being more lenient?
I wouldn't expect that at all, for the same reason I would expect
`let { x,
y } = { x: 1, y: 2, z: 3 }` to work.
And in Python, for example, I often get annoyed when the interpreter
reminds me that the length of an unpacked tuple must be the same as
the originating tuple, even if I'm intentionally ignoring the end of
it.
~TJ
This also. I think a common use case is to grab the items at the
beginning of a variable (or even unknown) length array. I also don't
see the benefit of requiring exact length matching, especially when it
would require adding additional syntax to bring back the ability to
work with variable/unknown length arrays.
We have talked of literals in the pattern language:
let {0:x, 1:y, length:2} = pair_only_please();
It's a pain to write an object pattern instead of an array, but this is
the exception to the rule, or would be were it supported. And it may be
in the future.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Machine readable specifications
Hi all
I'd like to discuss a radical change on how JS specifications and others
are constructed. I suggest int based rules are used to define language
behaviour. I know this works with last state and next state tracking and
expected states too maybe other behaviour could be defined this way as
well. The first part of the specification should define a list of ints that
correspond to the state starting from 0 with 0 being a start state of
Nothing. The initial states should be specified as follows:
initalStates = {0:Nothing,1:FunctionExpression, 2:FunctionStatement,
3:FunctionStatementIdentifier ...
Once every state is defined as an int, each state can be used in a lookup
table to determine the allowed last state and/or expected states. The
lookup table is used for error messages by the parser to convert the
corresponding int to human readable form. To define that FunctionStatement
can follow Nothing but FunctionExpression can't follow nothing and
FunctionStatementIdentifier is expected after FunctionStatement.
rules = {
//FunctionStatement State
2:{
lastStates: {
//FunctionStatement is allowed
after last state Nothing
0: true
},
expectedStates: {
//FunctionStatement expects the
next state to be FunctionStatementIdentifier
3:true
}
}
};
lastStates and expectedStates would also be ints but I added the text
for clarity, true could be shortened to 1 for compression. To use these
rules the parser can simply check the state machine which was the last
state and if the next state is valid. E.g.
lastState = 0;//Last state was Nothing
state = 2;//FunctionStatement state
if(rules[state].lastStates[lastState]) {
// FunctionStatement is allowed to follow Nothing
}
lastState = 0;//Last state was Nothing
state = 1;//FunctionExpression state
if(!rules[state].lastStates[lastState]) {
//FunctionExpression is not allowed to follow Nothing
error();
}
The same technique could be used for expected states since you'd just need
to lookup the next state with the assigned expected state from the last
state.
Once a machine readable specification has been done we could then generate
a human readable form of it based on the rules and it could be checked that
it conforms to what was intended. Both specifications (human readable and
machine readable) could be used by the implementer, when a specification
changes the parsers could automatically update based on the machine
readable form. Emulation for older parsers could be added within the
browser itself by using the new specification rules in a parser shim.
Thoughts?
Cheers
Gareth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
I expect that what you'll hear from implementers is that parsing isn't the
hard bit of a modern JS engine -- it's certainly not the thorniest part of
Traceur, and it doesn't do _most_ of the work a JIT-ing engine would.
If you would like to concretely improve the situation, you might ask Allen
and folks from engine teams what would simplify their jobs before proposing
a solution.
On Friday, March 22, 2013, gaz Heyes wrote:
Hi all
I'd like to discuss a radical change on how JS specifications and others
are constructed. I suggest int based rules are used to define language
behaviour. I know this works with last state and next state tracking and
expected states too maybe other behaviour could be defined this way as
well. The first part of the specification should define a list of ints that
correspond to the state starting from 0 with 0 being a start state of
Nothing. The initial states should be specified as follows:
initalStates = {0:Nothing,1:FunctionExpression, 2:FunctionStatement,
3:FunctionStatementIdentifier ...
Once every state is defined as an int, each state can be used in a lookup
table to determine the allowed last state and/or expected states. The
lookup table is used for error messages by the parser to convert the
corresponding int to human readable form. To define that FunctionStatement
can follow Nothing but FunctionExpression can't follow nothing and
FunctionStatementIdentifier is expected after FunctionStatement.
rules = {
//FunctionStatement State
2:{
lastStates: {
//FunctionStatement is allowed
after last state Nothing
0: true
},
expectedStates: {
//FunctionStatement expects the
next state to be FunctionStatementIdentifier
3:true
}
}
};
lastStates and expectedStates would also be ints but I added the text
for clarity, true could be shortened to 1 for compression. To use these
rules the parser can simply check the state machine which was the last
state and if the next state is valid. E.g.
lastState = 0;//Last state was Nothing
state = 2;//FunctionStatement state
if(rules[state].lastStates[lastState]) {
// FunctionStatement is allowed to follow Nothing
}
lastState = 0;//Last state was Nothing
state = 1;//FunctionExpression state
if(!rules[state].lastStates[lastState]) {
//FunctionExpression is not allowed to follow Nothing
error();
}
The same technique could be used for expected states since you'd just need
to lookup the next state with the assigned expected state from the last
state.
Once a machine readable specification has been done we could then generate
a human readable form of it based on the rules and it could be checked that
it conforms to what was intended. Both specifications (human readable and
machine readable) could be used by the implementer, when a specification
changes the parsers could automatically update based on the machine
readable form. Emulation for older parsers could be added within the
browser itself by using the new specification rules in a parser shim.
Thoughts?
Cheers
Gareth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 12:51, gaz Heyes gazhe...@gmail.com wrote:
I'd like to discuss a radical change on how JS specifications and others are
constructed. I suggest int based rules are used to define language
behaviour. I know this works with last state and next state tracking and
expected states too maybe other behaviour could be defined this way as well.
The first part of the specification should define a list of ints that
correspond to the state starting from 0 with 0 being a start state of
Nothing. The initial states should be specified as follows:
initalStates = {0:Nothing,1:FunctionExpression, 2:FunctionStatement,
3:FunctionStatementIdentifier ...
Aren't you confusing machine readable specification with machine
readable syntax specification? Syntax is only a small part of a
language spec, and quite frankly, the least interesting one by far.
Also, I don't see the benefit of your format. The EcmaScript spec
actually goes to quite some length to give a grammar that is LR(1).
The whole point is to keep it de facto machine readable. But unlike
yours, it also is human readable.
(FWIW, there are at least two serious efforts of actually formalising
and mechanising the JavaScript language, i.e. its _semantics_, which
is a much more interesting endeavor. Techniques for formalised
language specs have made a great leap over the last decade, and I
sincerely hope we'll see them becoming mainstream at some point. But
as usual, the mainstream is very conservative, probably for valid
reasons.)
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
The specification is hard enough to digest for average developers now; I'd hate to point one of my guys at a machine-readable document when he's having trouble with some corner-case. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 12:33, Andreas Rossberg rossb...@google.com wrote: Aren't you confusing machine readable specification with machine readable syntax specification? Syntax is only a small part of a language spec, and quite frankly, the least interesting one by far. Also, I don't see the benefit of your format. The EcmaScript spec actually goes to quite some length to give a grammar that is LR(1). The whole point is to keep it de facto machine readable. But unlike yours, it also is human readable. That was the reason to discuss, I think it could be applied to more than just syntax rules. You don't like it and that's fine with me I just wanted to post my ideas. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 12:36, Wes Garland w...@page.ca wrote: The specification is hard enough to digest for average developers now; I'd hate to point one of my guys at a machine-readable document when he's having trouble with some corner-case. You wouldn't do that, you'd point them to the human readable form. The machine version is specifically designed to be read by machines with low overhead to update functionality without touching code. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 08:41, gaz Heyes gazhe...@gmail.com wrote: You wouldn't do that, you'd point them to the human readable form. The machine version is specifically designed to be read by machines with low overhead to update functionality without touching code. Is there a formalized way to translate between the human and machine-readable specifications? If they are found to have different meanings (not hard to imagine), which specification would be considered authoritative? -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 12:57, Wes Garland w...@page.ca wrote: Is there a formalized way to translate between the human and machine-readable specifications? If they are found to have different meanings (not hard to imagine), which specification would be considered authoritative? The human readable form would be generated from the machine readable form. The human form should be a descriptive representation of the actual rules defined by the machine readable form. There should be no confusion only human error in understanding the descriptive text. The machine readable form should be authoritative since the idea is to implement whatever code based on the rules from the machine readable specification. To translate what I wrote in the initial mail into human form would be something like: Function Statement can follow Nothing and then expects Function Statement Identifier to follow. and Function Expression cannot follow Nothing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On 22 March 2013 13:37, gaz Heyes gazhe...@gmail.com wrote: On 22 March 2013 12:33, Andreas Rossberg rossb...@google.com wrote: Aren't you confusing machine readable specification with machine readable syntax specification? Syntax is only a small part of a language spec, and quite frankly, the least interesting one by far. Also, I don't see the benefit of your format. The EcmaScript spec actually goes to quite some length to give a grammar that is LR(1). The whole point is to keep it de facto machine readable. But unlike yours, it also is human readable. That was the reason to discuss, I think it could be applied to more than just syntax rules. You don't like it and that's fine with me I just wanted to post my ideas. You may be underestimating the challenge ;). If you are aiming for more than just syntax then you certainly wouldn't want a low-level encoding like the one you suggest. The standard approach to formalising a language is through a structured operational semantics over an abstract syntax, and the standard approach to making that accessible to a machine is encoding it in an established theorem prover or language like Coq or Isabelle or Agda or Twelf. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Patterns in parameter declarations: irrefutable?
On 20 March 2013 23:49, Axel Rauschmayer a...@rauschma.de wrote:
Thanks, didn’t know that applied to parameters, too. Then the following two
functions are equivalent(?)
function (arg0, arg1, arg2) {
// ...
}
function (...args) {
let [arg0', arg1', arg2'] = args;
// ...
}
With the following rules for translating argi - argi':
- paramName - ?paramName
- pattern - pattern (rest parameters, parameter default values, curly
braces, square brackets)
Not quite. In the latter form, default expressions could see all local
declarations from the function body, which we decided a couple of
meetings ago should not be the case for the former. More pedantically,
'paramName' should probably include parenthesized identifiers, and
'pattern' sloppy patterns ?pattern. (The latter also introduces a new
variable 'args' into the scope and produces a different length
property for the function, but let's ignore that.)
The more accurate desugaring probably is
function f(pat1, ..., patN, ...patR) { body }
into
function f() {
let pat1 = arguments[0]
...
let patN = arguments[N-1]
let [?*, ..., ?*, ...patR] = arguments
return (function(){ body })(...arguments)
}
(still ignoring the length property, and taking the liberty of using *
as a wildcard pattern to avoid inventing variable names).
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Regards, [1] https://gist.github.com/Ayms/2995641#another-approach-can-be-cajavm- Le 21/03/2013 22:17, Kevin Reid a écrit : Correction: On Thu, Mar 21, 2013 at 2:16 PM, Kevin Reid kpr...@google.com mailto:kpr...@google.com wrote: Yes. SES requires 'with' as a means to hook into 'global' variable reads and writes; without it, it is impossible without performing a parse and scope analysis of the code to be evaluated to emulate the semantics of browser global environments, such as in: ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mutable Proto
On Fri, Mar 22, 2013 at 6:03 PM, Aymeric Vitte vitteayme...@gmail.comwrote: As far as I remember when I looked at it, there was a getfreevar function or something like this parsing the code (or I misunderstood, see [1] but don't read the proposal, it's wrong, even if I don't totally give up with the concept). Are you referring to the function atLeastFreeVarNames at https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/atLeastFreeVarNames.js? It does scan the source using regular expressions to look for all possible identifiers. But it doesn't do a full parse or even lex. As a result, it picks up identifiers in comments and literal strings as well. Security only requires that the code being scanned cannot contain have a free (and therefore global) variable reference without it being included in atLeastFreeVarNames's result. But anyway, since it will change, does it exist an official document about SES concepts (strawman or other) ? Nothing official yet. But see https://code.google.com/p/google-caja/wiki/SES http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/37199.pdf Regards, [1] https://gist.github.com/Ayms/2995641#another-approach-can-be-cajavm- Le 21/03/2013 22:17, Kevin Reid a écrit : Correction: On Thu, Mar 21, 2013 at 2:16 PM, Kevin Reid kpr...@google.com wrote: Yes. SES requires 'with' as a means to hook into 'global' variable reads and writes; without it, it is impossible without performing a parse and scope analysis of the code to be evaluated to emulate the semantics of browser global environments, such as in: ___ es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
Andreas Rossberg wrote: FWIW, there are at least two serious efforts of actually formalising and mechanising the JavaScript language, i.e. its _semantics_, which is a much more interesting endeavor. Could you give (or point me to) details of these projects? I've done some work along these lines (though I'm not sure it qualifies as serious), so I'm wondering if I'm just reinventing the work of others. -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Machine readable specifications
On Fri, Mar 22, 2013 at 6:15 PM, Michael Dyck jmd...@ibiblio.org wrote: Andreas Rossberg wrote: FWIW, there are at least two serious efforts of actually formalising and mechanising the JavaScript language, i.e. its _semantics_, which is a much more interesting endeavor. Could you give (or point me to) details of these projects? I've done some work along these lines (though I'm not sure it qualifies as serious), so I'm wondering if I'm just reinventing the work of others. The two projects Andreas is referring to are: S5 and LambdaJS, by Arjun Guha and others: http://www.jswebtools.org/ Another, unnamed semantics, by Ankur Taly and others: http://jssec.net/ S5, which covers (almost) all of ES5, is still under development, and passes a large portion of Test262. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
Kenneth Russell wrote: I hope that the ES6 integration of typed arrays will not require normalization of NaNs on write, even if other specification changes need to be made to avoid requiring it. What other specification changes? JITs use nan-boxing (http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations). If a typed array user could forge a nan-boxed value, they could pwn the JITting VM. For interop, JS requires cross-browser (VM) NaN canonicalization to avoid observably different results on different browsers. Ergo, ES6 must specify normative handling of NaNs /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
On Mar 22, 2013, at 7:47 PM, Brendan Eich bren...@mozilla.com wrote: Kenneth Russell wrote: I hope that the ES6 integration of typed arrays will not require normalization of NaNs on write, even if other specification changes need to be made to avoid requiring it. What other specification changes? Ken means that we should change the part of the specification that states the invariant about multiple representations of NaN being unobservable, because he wants typed arrays to be allowed to break that invariant. I disagree with Ken. JITs use nan-boxing (http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations). If a typed array user could forge a nan-boxed value, they could pwn the JITting VM. For interop, JS requires cross-browser (VM) NaN canonicalization to avoid observably different results on different browsers. IMO this latter point is the most important: regardless of NaN-boxing, allowing different engines to non-deterministically produce one of several different bit patterns when writing a NaN into a typed array is under-specification and asking for portability bugs. Not only that, but I believe any time a web API designer wants to break a long-standing invariant of JS, particularly one that is stated *explicitly* in ECMAScript, the onus is on them to argue that they have a right to break that invariant. Ergo, ES6 must specify normative handling of NaNs Agreed. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Observability of NaN distinctions — is this a concern?
On Mar 20, 2013, at 1:57 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote: That normalization on read is is my case 1 above — it is necessary _for that implementation_. A conformant implementation could use a different strategy which does not normalize on Float64 read, and this would be unobservable, so the spec should not bother to specify it. However, lack of normalization on Float64 write _is_ potentially observable (if the implementation does not normalize all NaNs from all sources). Therefore, I argue, the spec should specify that normalization happens on write; and it happens that an implementation can omit that as an explicit step, with no observable difference, if and only if its representation of NaN in JS values (from all possible sources, not just typed arrays) is normalized. The buffer contents may have come form an external source or the buffer may be accessible for writes by an agent that is not part of the ES implementation. The only thing that the ES implementation has absolute control over are its own reads from a buffer and the values it propagates from those reads. I think you misunderstand what we mean here by write normalization. The goal here is not to ensure that specific bit patterns never appear in an ArrayBuffer. All possible bit patterns are and should be legal. Rather, the goal is to fully and deterministically specify that when the ES engine writes a NaN value into a Float32Array or Float64Array, a single canonical bit pattern is written into the ArrayBuffer. That is what ensures that it's impossible to distinguish different NaNs. (As for reads, the only thing the spec needs to say is that all possible NaN patterns are read as the JS NaN value. The particular bit representation of the JS NaN value itself is an implementation-specific thing and doesn't need any particular speccing.) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
