User-reifiable References
Context:
References are a specification-level construct that has no
language-level representation in current ES. Reifying
References as objects has been deemed troublesome/
inefficient for implementations.
Problem:
The lack of reified References is a blocking issue when trying
to define control operator libraries: user defined assignment
operators require at least References as arguments, some
operators might want to return References.
I keep running into this limitation, and examples like the '??='
in strawman:default_operator show I'm not the only one. So I
have looked for a workaround, and I think I've found a useful
option, on which I'd like your input.
Suggestion:
The starting point is the representation of References as an
object with a single getter/setter pair, so that reifying, eg.,
base[prop]
gives (*)
let reference = { get deref() { return base[prop] }
, set deref(v) { return base[prop] = v } }
This gives us an object that can be passed around, and can be
reflected back to an r-value or l-value, depending on context:
reference.deref = reference.deref + 1;
Of course, (*) is a handful, and gets worse when one tries to
share computation within 'base' and 'prop' between getter
and setter. No one is going to write this out by hand for every
reified Reference, or read code with lots of these without
struggling to see the simple intention behind the code.
The suggestion is to introduce a keyword phrase, so that
ref base[prop]
desugars to
(function(){
var _base = base;// private symbols _base, _prop;
var _prop = prop;// share evaluation of base, prop
return { get deref() { return _base[_prop] }
, set deref(v) { return _base[_prop] = v } }
}())
(and similarly for the other valid Reference phrases)
Then, a user-defined assignment operator, eg. matching the
strawman:default_operator's '??=', would be possible as
(ignoring infix syntax and multiple evaluation of 'r' here,
as those are separate issues)
function defaultAssign(r,def) {
return (r.deref = r.deref===undefined ? def : r.deref)
}
var x, y = 2;
defaultAssign(ref x,1);
defaultAssign(ref y,1);
// x === 1, y === 2
The readability improvement is so extreme that I doubt
anyone is using this pattern without syntax support?-)
Since reification of References happens only on request,
this has no performance implications for normal operation.
Since reification is a simple desugaring, implementing and
backtranslation into ES5 are not difficult.
Two questions come to mind:
1 where, exactly, does 'ref Reference' fit into the syntax
and post-syntax checks for valid References?
2 'ref' is not reserved, what about existing code using 'ref'?
As to 2, if 'ref' is in common use as a variable (a github search [1]
turns up some examples), I wouldn't mind having to import 'ref'
from some standard module before using it as a keyword, or
having local 'ref' declarations disable 'ref' as a keyword. That
way, users can migrate away from 'ref' as a variable, but don't
have to do so unless they want to use 'ref' as a keyword.
From what I can see, syntax support for user-reifiable References
would allow progress with control abstractions in JS, without
having to invoke or wait for the full complexity of macros for JS.
Without something like user-reifiable References, even simple
abstractions like assignment operators remain beyond the
reach of JS library coders.
Thoughts?
Claus
http://clausreinke.github.com/
[1] https://github.com/search?q=reftype=Codelanguage=JavaScript
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
2012/7/31 Brandon Benvie bran...@brandonbenvie.com You can still do useful things even without access to the public name though, as long as you can still forward to the target and get the result back. This allows you to instrument the action and to associate it with something unique even if you don't have a way to access the name and it's valuable arbitrarily outside of the trap. However, if there's no way to forward it correctly then the trap can't really exist at all anyway. No, if a handler intercepts a private name access for a private name it doesn't know, it has no way of forwarding the access in such a way that it can still intercept the result. That would allow the handler to read or change the value of a private name it doesn't know. The only way a handler can forward a private name access is by returning undefined from its getName trap. The forwarding at that point is done by the proxy, with no further interaction with the handler. The handler doesn't get to change the value returned from target[name]. This is crucial. AFAICT, the only two useful things a handler can do when it intercepts a private name it knows nothing about is: 1) ask the proxy to forward 2) throw If the handler does know of the private name, or the name is unique, then the handler can do the forwarding itself and intercept/change/decorate the result as usual. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: User-reifiable References
Claus Reinke wrote: Thoughts? As noted, we're moving away from References in the language. Macros are out there but the better way: you want to abstract over syntax, not runtime lvalue semantics. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
2012/7/30 David Bruant bruan...@gmail.com Le 28/07/2012 15:16, Tom Van Cutsem a écrit : We still want proxies to intercept private names. It may be that the proxy handler knows about the private name, in which case it has the capability to usefully intercept access to it. But it may be that the proxy doesn't know the private name for the very reason that the name holders do not want any proxy to know it. In that situation, why would the proxy trap be called? The proxy cannot make any constructive use of the public part without the private counter part, apart maybe from storing all public names it can and wait for a private name leak. Not trapping offers security by default. [analysis snipped] Is there a disagreement on my analysis? Is there a benefit in the public counterpart design I'm forgetting? I'm open to the idea of just not trapping private names (it would certainly simplify things), but like any part that proxies cannot virtualize, what would be the implications on self-hosting APIs? Of course, since private names don't yet exist, APIs such as the DOM do not make use of it. But we cannot guarantee that all APIs worth intercepting/virtualizing in the future will not make use of private names, only unique names. On the other hand, if we automatically forward private name access (no trapping), we should be aware that such accesses would pierce membranes. One could argue that the private name should never leak through the membrane in the first place. If private name access can be trapped, membrane proxies can throw when an attempt is made to access a private name the membrane doesn't know. You do seem to suggest that the current design unnecessarily elevates the risk of a private name leak by allowing trapping. A proxy can store all the .public objects it wants, that doesn't give it any more power. The confinement of the private name never rests on the confinement of the name.public property. I see no elevated risk of leaks in the current proposal due to a proxy hoarding public objects. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
It's definitely a concern of my that proxies have the necessary tools to allow for fully wrapping arbitrary object graphs. Is there any case where not being able to trap private names would prevent that goal? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Clarification on let/const
Hi,
I've been going through the spec trying to figure out a few edge cases
for block bindings. It appears that there is not a functioning demo for
these (Traceur is mostly working with var semantics, Firefox/Chrome are
not at all spec-compliant), so just thought I would ask to get a better
understanding of the expected behavior.
1. If I'm interpreting this correctly, let and const declarations will
throw an error if used with an identifier that is already defined within
the same block. So I think that means this should throw an error:
function f() {
var count = 10;
let count = 20; // error?
}
However, it seems like this would not (block variable shadowing function
variable?):
function f() {
var count = 10;
if (condition) {
let count = 20; // no error?
}
}
And I would assume this is the same (using let instead of var):
function f() {
let count = 10;
if (condition) {
let count = 20; // no error?
}
}
Am I correct in my understanding of these?
2. Since ECMAScript 6 is always running in strict mode, I'm assuming
that attempting to assign to a declared constant would throw an error
(in that it behaves similar to a non-writable property in strict mode)?
const MAX_ITEMS = 30;
MAX_ITEMS = 25;// error?
Is that correct?
Thanks,
Nicholas
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: July 25, 2012 - TC39 Meeting Notes
The following was WRT [[Put]]/[[CanPut]] semantic issues: On Jul 28, 2012, at 6:02 AM, David Bruant wrote: Le 28/07/2012 14:37, Herby Vojčík a écrit : ... :-/ But that is how it is, no? That's what the spec says, but V8 has implemented something else (and I haven't seen an intention to change this behavior), so what the spec says doesn't really matter. David I have to disagree with David's sentiments here. Situations like this is exactly why we have standardized specifications. Different implementors can easily have differing interpretations about the edge case semantics of loosely described features. An important role of standards is to align implementations on a common semantics. Sure, an implementation can refuse to go along with the specification but that is quite rare, at least for ECMAScript where all major implementations seem to recognize the importance of interoperability. In particular, I haven't seen any indication that V8, as a matter of policy, is refusing to ever correct this deviations. It's true that what the spec. says makes no difference to the browser bits that have already been shipped. It does make a difference over the long term. Single implementation deviations from the specification usually get fixed eventually. Conformance to the specs. is a motivator for implementors. We really shouldn't foster the meme that specs don't really matter. they matter a lot. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Clarification on let/const
On Jul 31, 2012, at 11:00 AM, Nicholas C. Zakas wrote:
Hi,
I've been going through the spec trying to figure out a few edge cases for
block bindings. It appears that there is not a functioning demo for these
(Traceur is mostly working with var semantics, Firefox/Chrome are not at all
spec-compliant), so just thought I would ask to get a better understanding of
the expected behavior.
1. If I'm interpreting this correctly, let and const declarations will throw
an error if used with an identifier that is already defined within the same
block. So I think that means this should throw an error:
function f() {
var count = 10;
let count = 20; // error?
}
yes
However, it seems like this would not (block variable shadowing function
variable?):
function f() {
var count = 10;
if (condition) {
let count = 20; // no error?
}
}
yes, shadowing of outer declarations by block level declarations is permitted.
And I would assume this is the same (using let instead of var):
function f() {
let count = 10;
if (condition) {
let count = 20; // no error?
}
}
Am I correct in my understanding of these?
yes
2. Since ECMAScript 6 is always running in strict mode,
this is no longer the case. ES6 has strict and non-strict modes just like ES5
I'm assuming that attempting to assign to a declared constant would throw an
error (in that it behaves similar to a non-writable property in strict mode)?
const MAX_ITEMS = 30;
MAX_ITEMS = 25;// error?
Is that correct?
yes, and this is isn't intended to be tied to strict mode. Also I don't see how
it relates to the cases you clarified above.
In the specification this is supposed to be covered by 10.2.1.1.3 step 6,
SetMutableBinding for a DeclarativeEnvironmentRecord. However, I note that
step 6 as currently written currently only throws in strict mode. This is a
carry over from the ES5 spec. where it very rarely came into play.
The easy fix of this is to simply eliminate the strict mode test in step 6.
But would introduce a minor semantic change from ES5:
In ES5, in the following code foo has an immutable binding within the body of
the function:
(function foo() {foo = 42}
however, it only throws if this is a strict mode function. Otherwise, the
assignment is just ignored.
If I simply make the spec. change to 10.2.1.1.3 step 6, it would be a breaking
change to any non-strict ES6 code that actually did something like the above.
The specification would be simpler if we were willing to make that breaking
change, but it may be too risky. One way or another the spec. will get fixed
so that assignment to a const binding throws.
Allen
Thanks,
Nicholas
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
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: July 25, 2012 - TC39 Meeting Notes
David Bruant wrote: That's what the spec says, but V8 has implemented something else (and I haven't seen an intention to change this behavior), so what the spec says doesn't really matter. I missed this until Allen's reply called it out. It is both false (Google people at the TC39 meeting last week said it's a V8 bug that is going to be fixed), and a stinky statement of anti-realpolitik. In the current market, if we don't hew to a consensus standard, anything goes. Not that everyone would make breaking changes, or any changes, just that from the presence of a bug or long-standing deviation (in this case copied from JavaScriptCore, which has since fixed the deviation!) does *not* mean that what the spec says doesn't really matter. Or were you snarking at V8? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Spec feedback on rev 6
Hi,
I've read pretty thoroughly through rev 6 of the spec (offline, with a
pen and a printed spec) and seem to have written down at least
something on pretty much every page.
It'll take me some time to put it all together digitally, but here are
some high level comments (in no particular order):
- String as code point values is not consistently propagated yet
- Would suggest to go a step beyond the code point value and leave out
unicode where not absolutely required (will explain in followup mail)
- The double point unicode characters (and the \u{x*} extension) smell
a lot like the mb_ mess php left when moving to utf (not sure
whether this could be solved easily though)
- Completion reform has the same problem of inconsistently being
propagated in old parts of the spec, i dont think all return values
are properly handled yet
- typeof null still object (personal disappointment :)
- Make undefined, NaN, and Infinity a literal (I don't see what issues
that might cause, please tell me if any); they're locked down anyways
- Many inconsistencies (different ways of doing the same thing in
algorithms, explaining things, and even the grammar)
- Quite a bit of duplication that could be prevented
- The term exotic does not seem fitting to this spec, but even if
that bikeshed is not reverted; host and native have still _many_
occurrences
- Likewise for character (also inconsistently replaced with one of
code point, code point value, element, and code unit)
- Missing some of the interesting parts I was looking forward to
reading specced (WeakMaps, Proxies, etc)
- I think many of the built-in functions and methods could do with a
short description (more than func, when called, does this algo:)
- Many, many of the algorithms, notes, and rules could do with one or
more examples and the rationale behind them.
- The new way of doing static semantics are really annoying to read
(especially offline) when split up like this
- When referring to certain abstract (-like) functions, like static
semantics, it's really hard to detect this while reading (example:
contains), style issue
- Large chunk of the parsing theory seems to be irrelevant (spec would
be useful even without it)
- The new additions seem to take a few shortcuts wrt the grammar.
Especially re-parsing rules look a bit weird over just one grammar
- Making new parts of the spec (modules, using let, using const, etc)
auto strict mode is really disappointing and will confuse users, new
and experienced
I'm sure there's one or two more. So I've got two questions before I
start digitization of my notes...
1: For what kind of audience does the TC39/ECMA target this spec? To name a few:
- Academics (proofs, formalization, background theory)
- Implementors (edge casing, exact algorithms, no need for formal
proof or background theory)
- Advanced coders wanting to jump to the next level (how does it work,
rationales, examples)
- Coders wanting to learn (ok, probably not)
I think it's either 1, 2, or both. But while reading the spec I could
not really get a good feeling and it seems to be a mix between the
first, second, and maybe even the third type. An answer to this
question helps me to determine which items I might ignore :)
2: How would you like me to do this?
I can write a single email to this list for every (bigger) issue I
found, but I don't want to spam the list. A single email will make
individual points get lost in messy comments very fast though. I could
add every point to a github-gist for people to comment on, but that
would require a github account for people to comment there (not sure
how big of an issue this is). I could go through the list with
somebody to filter out the smaller points, through irc or skype? Could
make typo-part quicker to do. Please let me know :)
Learned a few new things while reading the spec (including some things
I think I actually missed/forgot while reading the es5 spec a few
years ago), so it's not been in vain regardless :)
Cheers,
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: July 25, 2012 - TC39 Meeting Notes
On Sat, Jul 28, 2012 at 6:02 AM, David Bruant bruan...@gmail.com wrote: That's what the spec says, but V8 has implemented something else (and I haven't seen an intention to change this behavior), so what the spec says doesn't really matter. We have a fix for V8 (--es5_readonly) but the Chromium bindings to the DOM still has bugs related to this flag. I plan to have this fixed in the coming weeks. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: July 26, 2012 TC39 Meeting Notes
2012/7/31 Tom Van Cutsem tomvc...@gmail.com 2012/7/30 David Bruant bruan...@gmail.com Le 28/07/2012 15:16, Tom Van Cutsem a écrit : We still want proxies to intercept private names. It may be that the proxy handler knows about the private name, in which case it has the capability to usefully intercept access to it. But it may be that the proxy doesn't know the private name for the very reason that the name holders do not want any proxy to know it. In that situation, why would the proxy trap be called? The proxy cannot make any constructive use of the public part without the private counter part, apart maybe from storing all public names it can and wait for a private name leak. Not trapping offers security by default. [analysis snipped] Is there a disagreement on my analysis? Is there a benefit in the public counterpart design I'm forgetting? I'm open to the idea of just not trapping private names (it would certainly simplify things), but like any part that proxies cannot virtualize, what would be the implications on self-hosting APIs? Of course, since private names don't yet exist, APIs such as the DOM do not make use of it. To some extent, we can say that they do. dom.js uses _properties to discriminate what's private. So, that's where they use private names if they had them. It certainly gives a good sense of where private names would be used in a self-hosted DOM. Other libraries use that convention (especially in Node.js from what I've seen), so that could give an idea. But we cannot guarantee that all APIs worth intercepting/virtualizing in the future will not make use of private names, only unique names. true. Flexibility is an interesting and important argument. On the other hand, if we automatically forward private name access (no trapping), we should be aware that such accesses would pierce membranes. One could argue that the private name should never leak through the membrane in the first place. If private name access can be trapped, membrane proxies can throw when an attempt is made to access a private name the membrane doesn't know. You do seem to suggest that the current design unnecessarily elevates the risk of a private name leak by allowing trapping. A proxy can store all the .public objects it wants, that doesn't give it any more power. The confinement of the private name never rests on the confinement of the name.public property. I see no elevated risk of leaks in the current proposal due to a proxy hoarding public objects. I didn't say that, I said that the outcome of a leak is bigger if a proxy can store the public parts and wait for a private name leak, but I realize I was mostly wrong on that point. Public parts do not increase the things one can reach in case of a leak in a meaningful way. It just make it more efficient to search for things. 2012/7/31 Tom Van Cutsem tomvc...@gmail.com 2012/7/31 Brandon Benvie bran...@brandonbenvie.com You can still do useful things even without access to the public name though, as long as you can still forward to the target and get the result back. This allows you to instrument the action and to associate it with something unique even if you don't have a way to access the name and it's valuable arbitrarily outside of the trap. However, if there's no way to forward it correctly then the trap can't really exist at all anyway. No, if a handler intercepts a private name access for a private name it doesn't know, it has no way of forwarding the access in such a way that it can still intercept the result. That would allow the handler to read or change the value of a private name it doesn't know. The only way a handler can forward a private name access is by returning undefined from its getName trap. The forwarding at that point is done by the proxy, with no further interaction with the handler. The handler doesn't get to change the value returned from target[name]. This is crucial. I think I missed the *Name trap design in the notes. Returning [name, value] looks very heavy to me. If you know a secret once and can prove it once, you can know it and prove it forever (and very likely will), so the API should take that property into account. One idea would be to have a particular property in handlers, like knownPrivateNames (which could smartly be expected to be an ES.next Set, or more accurately a WeakSet if this one ever gets mentionned in the spec) and whenever an *Trap returns for a particular private name, the after-trap checks whether you have the private name in your knownPrivateNames set. That should be enough to prove you know the secret. When you get to a new private name, put it in the knownPrivateNames set. Even in the return [name, value] design, one needs to store known private names somewhere anyway and it'll likely be on the handler anyway too :-) So it may be a good idea to make this storage official and make it a tool to communicate with the JS engine. Maybe the
Re: Spec feedback on rev 6
On Tue, Jul 31, 2012 at 10:19 PM, Peter van der Zee e...@qfox.nl wrote: Hi, I've read pretty thoroughly through rev 6 of the spec (offline, with a Sorry, I may have been confused. I read the July 8th revision of the draft. Fwiw. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: User-reifiable References
As noted, we're moving away from References in the language.
l-values as function parameters are still going to be useful,
for abstractions involving assignment operators.
Macros are out there but the better way: you want to abstract over syntax, not runtime lvalue
semantics.
Useful macros are going to have a lot of expressive power
over syntax, which tends to go along with decreased ability
to reason about code. Functions are not as simple in JS as
they are in other functional languages, but it still seems
advisable to do as much as possible without macros.
I've updated my infix operator gist, to include initial support
for 'ref', and also to wrap operator arguments - so both
assignment operators and short-circuiting operators are
now possible. Unwrapping of arguments and reference
objects is done explicitly in operator definitions.
https://gist.github.com/3157251
See example 6 (strawman:default_operator, .??, .??=) in
https://gist.github.com/3157251#file_sample.js
The expected output (for those who don't want to clone and run
the gist) can be seen in the comments of
https://gist.github.com/3157251#file_infix.js
In this gist, the desugaring of 'ref' and infix operators corresponds
to hard-coded macros, doing the things with syntax that cannot
be done with functions alone. The rest is handled by function
definitions and conventional code.
Until macros make it into the language, this is an easy way
to play with suggested operators (factoring out the parser
hacking, some of which is still TODO).
Example extract:
Operator['.??='] =
function(lhs_,rhs_){
var lhs = lhs_();
var value = lhs.deref;
return (lhs.deref = ( value!==undefined ? value : rhs_()))
};
(function(){
var x;
console.log('6(assignment x):', ref x .??= 1);
console.log('6(assignment x):', x );
}());
Output extract:
6(assignment x): 1
6(assignment x): 1
Btw, I've also added (example 7) a simple version of Allen's new
strawman:define_properties_operator, '.:=' .
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: July 25, 2012 - TC39 Meeting Notes
I think my message has been taken the wrong way, so I should clarify it: From a practical point of view, if 2 implementations differ on one aspect of the language, it means that there is no content relying on either of the 2 implementations for that aspect of the language, whether they follow the spec or even both diverge differently from it. Not having content relying on this aspect also opens the door to changing the behavior if it's considered as a mistake. This applies to the override mistake, but every single test262 test failure on any major implementation could also be seen as an instance of such an open door to change the spec. what the spec says doesn't really matter seems very negative taken out of context, but within the context i said it, it meant something positive along the lines of there is room to improve the specification on this part if necessary That really is all what I meant, no more, no less. Also... hmm... I wouldn't be spending that much time on standards mailing-list, this one included, if I didn't believe in standardization ;-) Detailed answer below. Le 31/07/2012 14:07, Allen Wirfs-Brock a écrit : The following was WRT [[Put]]/[[CanPut]] semantic issues: On Jul 28, 2012, at 6:02 AM, David Bruant wrote: Le 28/07/2012 14:37, Herby Vojčík a écrit : ... :-/ But that is how it is, no? That's what the spec says, but V8 has implemented something else (and I haven't seen an intention to change this behavior), so what the spec says doesn't really matter. David I have to disagree with David's sentiments here. Situations like this is exactly why we have standardized specifications. I agree. But I'd like to add that situations like this also show the limitations of standardized specifications (more on that at the end) Different implementors can easily have differing interpretations about the edge case semantics of loosely described features. An important role of standards is to align implementations on a common semantics. Sure, an implementation can refuse to go along with the specification but that is quite rare, at least for ECMAScript where all major implementations seem to recognize the importance of interoperability. I do the opposite analysis: major implementations recognize the importance of interoperability due to market constraints, thus the need for a standard. Although almost no one talks about it these days, I think the most important part of HTML5 was specifying what's already in some browsers, making clear for the other browsers what to implement to be interoperable. In particular, I haven't seen any indication that V8, as a matter of policy, is refusing to ever correct this deviations. It's true that what the spec. says makes no difference to the browser bits that have already been shipped. It does make a difference over the long term. Single implementation deviations from the specification usually get fixed eventually. Conformance to the specs. is a motivator for implementors. We really shouldn't foster the meme that specs don't really matter. they matter a lot. I hope I have clarified that I don't buy into the meme that specs don't matter. I was only reacting to the fact the 2 major implementations differ on one aspect of the spec, making in practice what the spec says on that aspect useless. Brendan Eich wrote: I missed this until Allen's reply called it out. It is both false (Google people at the TC39 meeting last week said it's a V8 bug that is going to be fixed) it's unfortunate this information wasn't on the meeting notes, but I'm glad to hear it :-) and a stinky statement of anti-realpolitik. In the current market, if we don't hew to a consensus standard, anything goes. Not that everyone would make breaking changes, or any changes, just that from the presence of a bug or long-standing deviation (in this case copied from JavaScriptCore, which has since fixed the deviation!) does *not* mean that what the spec says doesn't really matter. I guess I should have added here at the end of my sentence to clarify that I didn't mean that the whole spec doesn't matter, but only the part about [[CanPut]]/[[Put]] that's not interoperably implemented. Or were you snarking at V8? I was not. More on the limitations of standardization I talked about above. As I said, I understand the importance of a standard and I don't buy in the idea they are useless. I also don't buy in the idea that standards should be seen written-in-stone documents. We all know that specs sometimes have mistakes in them and when it's necessary and possible, they are fixed. It was discovered that ES5 had such a mistake [1] and the standard has been consequently fixed. This change additionally to implementations following make that what was said in the spec about Object.prototype.toString before the fix did not matter (only the part that was controversial). The fact that it did not matter was actually a pre-requisite to being
Re: Spec feedback on rev 6
Thanks, Peter. This makes me realize that I probably need to write a short
guide to reading and reviewing drafts of the specifications. As a first
approximation I'll address some of your issues here and then probably reuse
some of this material in putting together such a guide.
The best way to report problems with ES6 drafts is to file bugs at
bugs.ecmascript.org. Use the product Draft of the 6th Edition , the version
you are reading, and an appropriate component (editorial issues, technical
issues, etc.). This is particularly useful for specific bugs such as
misspellings or errors in algorithms.
All draft, at least through most of this calendar year, are snapshots taken of
my working drafts at fairly arbitrary points in time. They are still far from
being complete, often have incomplete treatment of new features, and sometimes
are captured in the middle of some major refactoring. It is reasonable to
assume that I am aware of the major inconsistencies or missing material, but
you can't over report. So if you see something that you think is important to
capture, file a bug. For example, the new conventions for dealing with
completion values (this is actually something different from we refer to as
completion reform on the wiki) is largely done but I still need to do a
comprehensive review to make sure I've gotten everything that needs to be
modified. If you saw places where you think I missed something in that regard,
please file a bug.
Some of you issues are questions regarding ES6 design decisions, such as the
\u{} escape and the automatic UTF-16 encoding of Unicode supplementary
characters. If you want to discuss why these decisions were made or want to
argue for an alternative then you should post messages about specific issues to
es-discuss. Most of TC39 reads this list, while I'm the main person reading
and responding to bug reports. So, if you want wider discussion, use es-discuss.
Grammar anomalies you see are either issues that derive from ES's contextual
dependencies between lexing and parsing or from the committee desire to have a
generally LR(1) grammar. In some cases, we can only accomplish the latter by
using a overly permissive cover grammar and then reparsing with a more
restrictive contextually determined grammar. If you have a better way to
handle such situations, feel free to start an es-discuss thread.
Similarly, with the use of static semantic (and, for that matter, runtime
semantic rules). As the language grows, it has a richer set of semantics that
we have to describe. If you have techniques that are both better and practical
for an incremental rewrite I'd be happy to discuss them on es-discuss. I'm
also experimenting with other ways to deal the the complexity such as the
static semantic cross reference in annex F and various forms of indices and
internal hyper-links.
Regarding, the target audience. I consider the primary audience to be
implementors who must create highly interoperable ES implementations. In one
sense, it is all about the edge cases that implementors must get exactly right
in order to be completely interoperable. Next comes the authors of
interoperability and conformance test suites, such as test262. They need to
write tests that help implementor conform to the specification. For third in
priority, I would place sophisticated authors and educator. These are the
people who will teach the language to the world, and like implementors, they
need to know (or at least lookup) edge case behavior. This is not a document
for everyday ES codes (although some will use it). It is also not a tutorial
on either language design in general, language theory, or the design process
behind its creation. The spec. also isn't particularly targeted towards
academics. We certainly want to have a sound language and where necessary TC39
members may even prove characteristics of certain features. But such material
is not necessarily included in the specification. We don't bias our
specification technique specifically towards the preferences of academics. If
I had to make a choice between usability (of the spec.) for implementors and
usability for academics I would make the choice that favored implementors.
We generally try to minimize tutorial material (eg examples) and redundancy
between normative prose descriptions and normative algorithms. Redundant
descriptions has historically resulted in internal inconsistencies. We have
also seen cases where implementors follow incomplete prose descriptions without
referring to the more complete algorithm. For these reasons, I have been
converting much of the redundant prose from previous editions into
non-normative notes. In general, examples are only used if they seem necessary
to clarify some difficult to understand normative point. Sometimes I will
insert an example in order to make it clear that some unusual design point is
intentional and not a bug in
Re: July 25, 2012 - TC39 Meeting Notes
David Bruant wrote:
From a practical point of view, if 2 implementations differ on one
aspect of the language, it means that there is no content relying on
either of the 2 implementations for that aspect of the language,
whether they follow the spec or even both diverge differently from it.
It's not that simple on the web. For instance, longstanding IE vs.
Netscape/Mozilla forking, e.g.
if (document.all) { ... } else { ... }
can mean some divergence among the else browsers is ok because not
relied on there, but not ok in the then case.
You're probably right, but we are not making data and accessors
asymmetric in the sense that a non-writable data property and a get-only
accessor on a prototype object both throw (strict) or silently fail to
update the LHF (non-strict) on assignment that would otherwise create a
shadowing property in a delegating object.
This was debated at last week's TC39 meeting. Between the desire to
preserve this symmetry (not paramount, there are many dimensions and
symmetries to consider) and the V8 bug being fixed (and the JSC bug on
which the V8 bug was based already being fixed in iOS6), I believe we
kept consensus to follow the spec.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Default constructor and extends null
At the face to face meeting we agreed that if no constructor is
present in a class a default one is provided as if the following
constructor was present.
class C extends null {
constructor(...args) {
super(...args)
}
}
What should this do when C extends null? If this was manually added I
would prefer that this would be a runtime error. Should we special
case this and use an empty constructor if the super class is null?
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: July 25, 2012 - TC39 Meeting Notes
On Wed, Aug 1, 2012 at 12:05 AM, Brendan Eich bren...@mozilla.org wrote: (and the JSC bug on which the V8 bug was based already being fixed in iOS6) Just to nitpick for those following along at home, the bug is fixed in the just-release *Safari* 6, and @ohunt declined to comment on future products or releases :) -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default constructor and extends null
Erik Arvidsson wrote:
At the face to face meeting we agreed that if no constructor is
present in a class a default one is provided as if the following
constructor was present.
class C extends null {
constructor(...args) {
super(...args)
}
}
What should this do when C extends null? If this was manually added I
would prefer that this would be a runtime error.
Agreed. Allen probably has a thought. I think we just did not discuss
this case, or overlooked it.
Should we special
case this and use an empty constructor if the super class is null?
+1.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
