We had this in ES4, together with the provision that you could have multiple
arguments between the [], so you could define data structures that can be
addressed as:
matrix2d[x, y]
As in here, this would default to the ES5 semantics on objects that don't have
the new [] proxy handler.
On 10/19/2011 08:16 AM, Allen Wirfs-Brock wrote:
Does anybody know or see a good reason why FunctionExpressionshouldn't be move
as a RHS of PrimaryExpression? MemberExpressionis the only occurrence of either
PrimaryExpressionor FunctionExpressionon the RHS of a grammar rule.
As you note, the
On 11/02/2011 04:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name === other@name;
}
}
-
I am under this impression that you are accessing the private property
(other@name) of an instance which isn't you (other !== this)
Please keep bringing these up; they're important.
This is something that we'll need to get nailed down for the spec. Yes, I'm
worried too, as this problem is not well-understood. It has the feel of a
research problem.
Waldemar
___
es-discuss
On 09/30/2011 08:43 PM, Brendan Eich wrote:
On Oct 1, 2011, at 5:24 AM, Brendan Eich wrote:
On Oct 1, 2011, at 4:23 AM, Waldemar Horwat wrote:
There are lots of ways to do classes that satisfy all of 2-5. However, it
doesn't matter if those exist if those solutions are not acceptable
On 09/30/2011 01:20 AM, Brendan Eich wrote:
On Sep 30, 2011, at 2:38 AM, Waldemar Horwat wrote:
On 09/29/2011 05:08 PM, Bob Nystrom wrote:
On Thu, Sep 29, 2011 at 4:22 PM, Erik
Arvidssonerik.arvids...@gmail.commailto:erik.arvids...@gmail.com wrote:
However, it seems like all
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
That's what makes this into a dead end. Worse, by claiming the class syntax
you'd be precluding finding a different way that works in the future.
Waldemar
On 09/30/2011 06:51 PM, Brendan Eich wrote:
On Oct 1, 2011, at 3:34 AM, Waldemar Horwat wrote:
On 09/30/2011 05:07 PM, Brendan Eich wrote:
On 09/30/2011 04:37 PM, Brendan Eich wrote:
since we haven't come up with a way to do 2 and 5 that works,
We can add these later ...
Those two
On 09/29/2011 05:08 PM, Bob Nystrom wrote:
On Thu, Sep 29, 2011 at 4:22 PM, Erik Arvidsson erik.arvids...@gmail.com
mailto:erik.arvids...@gmail.com wrote:
However, it seems like all the issues we have seen are due to us
trying to solve issues that already exist today with prototype
Thinking about the implications of paren-free, I see additional potential
trouble spots in addition to the one I mentioned in the meeting yesterday:
Start with ES5 code:
if (a + b)
(x.y)()
z++
Now (erroneously) convert it to paren-free:
if a + b
(x.y)()
z++
This doesn't give a syntax
Rough notes from today's meeting.
Waldemar
Classes:
What do you get when you access an instance property before the directive
defining it has been executed?
A. Throw (just as in temporal dead zone for let/const variables)
B. Get undefined
C. Property does not exist yet on the object --
My rough notes for today's meeting.
Waldemar
Test262.ecmascript.org presentation
Allen: There will be substantial changes to section numbering in ES6.
Concerned about too much dependence on section numbers in Test262. However,
there exist tools to rename Test262 files with new section
On 06/01/11 18:47, Breton Slivka wrote:
Yes, if you make it mandatory to parenthesize statements then this would
work, except for the important case of blocks.
Waldemar
This might be a pretty radical (or stupid) thing to ask, but what if a
block with labeled statements were semantically
Did you mean to disallow an expression as the first statement in your block?
Waldemar
On 06/01/11 18:49, Mike Samuel wrote:
2011/6/1 Waldemar Horwatwalde...@google.com:
Yes, if you make it mandatory to parenthesize statements then this would
work, except for the important case of blocks.
On 06/02/11 13:43, Mike Samuel wrote:
Yes. That grammar is a subset of the grammar that results from
replacing the 11.1.6 ' PrimaryExpression : ( Expression ) '
production with
( GroupElement GroupElements )
where GroupElement is defined as any Statement except for Block and
On 06/02/11 17:56, Kyle Simpson wrote:
Is it available for general public members to register for an account to create
strawman proposals for ES?
No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent covenant
so this can't be a free-for-all, for better or worse.
So if a
On 06/01/11 01:32, Kam Kasravi wrote:
On May 31, 2011, at 4:20 PM, Waldemar Horwatwalde...@google.com wrote:
On 05/29/11 19:35, Kam Kasravi wrote:
Does Waldemar still maintain the tool? the source dates seemed fairly old...
It still works. I didn't bother updating the ES3 parser for ES5
On 05/27/11 19:36, Brendan Eich wrote:
On May 27, 2011, at 6:42 PM, Brendan Eich wrote:
On May 27, 2011, at 6:20 PM, Waldemar Horwatwalde...@google.com wrote:
This produces expressions such as 42 = foo(), which must be handled by semantic
specification. Why can't we have a more precise
On 05/31/11 13:34, Brendan Eich wrote:
On May 31, 2011, at 1:21 PM, Waldemar Horwat wrote:
On 05/27/11 19:36, Brendan Eich wrote:
On May 27, 2011, at 6:42 PM, Brendan Eich wrote:
On May 27, 2011, at 6:20 PM, Waldemar Horwatwalde...@google.com wrote:
This produces expressions such as 42
On 05/31/11 14:30, Waldemar Horwat wrote:
On 05/31/11 13:34, Brendan Eich wrote:
On May 31, 2011, at 1:21 PM, Waldemar Horwat wrote:
On 05/27/11 19:36, Brendan Eich wrote:
On May 27, 2011, at 6:42 PM, Brendan Eich wrote:
On May 27, 2011, at 6:20 PM, Waldemar Horwatwalde...@google.com wrote
On 05/31/11 14:55, Brendan Eich wrote:
On May 31, 2011, at 2:30 PM, Waldemar Horwat wrote:
I would not want to use anything like a PEG to standardize a grammar. Here's
why:
PEG being unambiguous by construction simply means that it resolves all
ambiguities by picking the earliest rule
On 05/29/11 07:00, Dmitry A. Soshnikov wrote:
Yeah, and ES also supports them. It's called a generator expression; in this
proposal it would look like:
let squares = (x * x | x data, x 5);
Ahem, that's already a parenthesized comma expression with operands
x * x | x data
and
x 5.
On 05/29/11 19:35, Kam Kasravi wrote:
Does Waldemar still maintain the tool? the source dates seemed fairly old...
It still works. I didn't bother updating the ES3 parser for ES5 because I had
already explored the same syntax as part of ES4 and it worked. I'm going to
update it for
On 05/27/11 02:01, Brendan Eich wrote:
More was said here that is good feedback for Harmony, no matter what gets into
ES.next.
We talked about how shorter function syntax is hard to do well and standardize.
The traps include:
* do too little by ignoring 'return', jumping a syntax shark and
On 05/27/11 16:00, Brendan Eich wrote:
On May 27, 2011, at 12:27 PM, Waldemar Horwat wrote:
Peter Hallam kindly offered to help come up with a new grammar formalism for the spec
that can pass the Waldemar test (if that is possible; not as hard as the
Turing test). IIRC Peter said he was (had
This seems too brittle to me. The examples conveniently include only lambda
parameters in their function calls. Suppose you have:
a = f{|| 42}
and want to add a second lambda parameter:
a = f{|| 42}{|x| x*x}
So far so good, ignoring the little bug that || is a different token than two
|'s
On 05/21/11 23:53, Brendan Eich wrote:
That's accurate. But I discounted arrow functions because to be usable, to have
the syntax you show above, requires GLR parsing (if bottom up; top-down may be
easier, haven't proven it yet).
GLR parsing would be wild in ECMAScript due to the fact that
On 05/23/11 16:20, Brendan Eich wrote:
On May 23, 2011, at 1:44 PM, Waldemar Horwat wrote:
(we've yet to have a coherent discussion about what really can go into these
parameter lists).
I gave the grammar with semantics -- did you read it?
Yes. However I don't think it'd be tenable
On 05/23/11 17:26, Brendan Eich wrote:
On May 23, 2011, at 5:12 PM, Waldemar Horwat wrote:
On 05/23/11 16:20, Brendan Eich wrote:
On May 23, 2011, at 1:44 PM, Waldemar Horwat wrote:
(we've yet to have a coherent discussion about what really can go into these
parameter lists).
I gave
On 05/23/11 18:09, Brendan Eich wrote:
On May 23, 2011, at 5:43 PM, Waldemar Horwat wrote:
I don't have a simple fix in mind. What's making me dubious about this is that
this is a function calling syntax that can supply a bunch of literal functions
as arguments, but they must all be literal
On 05/16/11 11:11, Allen Wirfs-Brock wrote:
I tried to post a pointer to this strawman on this list a few weeks ago, but
apparently it didn't reach the list for some reason.
Feed back would be appreciated:
http://wiki.ecmascript.org/doku.php?id=strawman:support_full_unicode_in_strings
Allen
I placed guards and trademarks on the agenda for this month's meeting. They're
intentionally a relatively bare-bones and secure mechanism:
http://wiki.ecmascript.org/doku.php?id=strawman:guards
http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
These partially rely on a mechanism for
Here are my notes from today's meeting.
Waldemar
DaveH's presentation on using generators to write asynchronous code.
How do you compose generators? yield*
Waldemar: Given yield*, writing base-case trivial generators that
don't yield becomes useful but its syntax is
Here are my raw notes from the last couple days.
Ask the GA for a way for non-members to sign software contribution agreements?
Waldemar: Thinks this would be a hard sell in the GA. They'll be
annoyed at increasing provisions for non-members to participate.
Istvan: This should not be too
On 03/21/11 13:13, Erik Arvidsson wrote:
The thread about using private names is getting a bit unwieldy but I'd
like to focus on the use case that I have been thinking of as
Lexically scoped monkey patching or Lexically scoped object
extensions instead of focusing on how to use private names to
On 03/21/11 17:42, Allen Wirfs-Brock wrote:
On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:
The above use case cannot be solved using private names because
private names conflict with public names.
Erik, I'm not sure that my understanding of the intended semantics of your
extension
On 02/25/11 13:26, Brendan Eich wrote:
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
On 2/25/11 4:08 PM, David Bruant wrote:
I would tend to be more in favor of disallowing Harmony features in
non-strict code (without explicit use strict directive) to avoid
surprises (I'm nuancing below).
On 02/20/11 21:16, Mark S. Miller wrote:
The specification of Math.LOG10E says:
15.8.1.5 LOG10E
The Number value for the base-10 logarithm of e, the base of the natural
logarithms; this value is approximately 0.4342944819032518.
This property has the attributes { [[Writable]]:
Once again, here are my raw meeting notes.
Waldemar
--
Discussion of isNaN and isFinite.
Can/should we fix these in place rather than creating more functions?
Allen: Existing usage is consistent with normal numeric coercions
done by other operators such as -.
Doug: Would it
Here are my rough notes for today's meeting.
Waldemar
--
Internationalization standard: Part of E262 or separate track? Pros
and cons to each one, and either would be workable. There is a
substantial area of interaction (ES5 locale methods, normalization,
and such) between
On 11/23/10 11:12, Brendan Eich wrote:
for (k in keys(o)) ...
for (v in values(o)) ...
for ([k, v] in properties(o)) ...
What are keys, values, and properties here? Global functions? How would
a new object abstraction T customize them just for instances of T?
Waldemar
On 11/22/10 20:18, Bga wrote:
// es3 way
(function()
{
var x = 1;
return function()
{
return ++x;
}
})();
// current es6/SM1.8 way
let(x = 1) function()
{
return ++x;
}
// new more readable sugar
function()
{
static x = 1; // hello c/c++
return ++x;
}
On 11/23/10 13:05, David Herman wrote:
How would a new object abstraction T customize them just for instances of T?
By writing its own custom iteration protocol via proxies with the iterate()
trap implemented appropriately. E.g.:
function MyCollection() { }
MyCollection.prototype = {
On 11/23/10 15:18, Allen Wirfs-Brock wrote:
- How far does static hoist? One let-scope? One block-scope? One
function-scope? One class-scope?
AWB: the simple answer would be one block-scope (isn't that the same as
a let-scope??). It probably will take some experimentation to verify
that the
On 11/22/10 10:13, Brendan Eich wrote:
{ foo : G : 33 }
0. let typedObj = { foo : 33 } : { foo : G }; // a la ES4
1. let typedObj = { foo :: G : 33 }; // the guards strawman
2. let typedObj = { (foo : G) : 33 }; // the ML-ish way
3. let typedObj = { foo @ G : 33 };
On 11/22/10 15:16, Brendan Eich wrote:
{name: type = value} // Adding a type annotation
Isn't the last ambiguous with legal JS today (well, with const, but that's not
important AFAICT):
Yeah, you're right. This won't work.
Waldemar
___
Third day rough meeting notes.
Waldemar
instanceof trap for proxies: Withdrawn. Agreed to drop it for now.
Proxy default forwarding handler. Agreed that there should be an easy
way to delegate to a default forwarding handler.
Waldemar: Why not use prototypes to do this?
MarkM, others:
Here are my meeting notes for today.
Waldemar
WebIDL: Can abstract interfaces have static members? Don't see why
not -- they'd just be spec sugar for adding the same static member to
concrete classes that derive from those abstract interfaces. As
usual, it would be a spec error to have a
Here are my very rough notes for today's IDL discussions. In many
cases I couldn't tell what was actually decided rather than merely
discussed.
Waldemar
IDL day: Lots of discussions, exploring various points and making
suggestions. Mostly exploratory -- not in the proper frame
On 11/12/10 15:04, Brendan Eich wrote:
On Nov 12, 2010, at 2:52 PM, Marc Harter wrote:
After considering all the breadth this discussion could take maybe it
would be wise to just focus on one issue at a time. For me, the biggest
missing feature is lookbehind. Its common to most languages
On 10/14/10 08:11, Brendan Eich wrote:
On Oct 13, 2010, at 11:56 PM, Erik Corry wrote:
The semantics for const in Harmony are likely to be silently different
in Harmony from the semantics it has in non-strict current
implementations. (In particular the current const is hoisted to the
On 10/01/10 18:49, Brendan Eich wrote:
It's not clear what private names are trying to do well. If they want
to provide privacy, they can't be visible to proxies. If they want to
provide extension without collision (i.e. namespacing), they should be
visible to Object.keys, enumeration, etc.
Here are my raw notes from our second day.
Waldemar
Catch guard proposal, resurrected from 1998. Well-liked all around.
Proposed to move into Harmony if there are no objections by the next
meeting.
MarkM speculating: Could the if syntax be extended to pattern
matching? Not easily.
Here are my raw notes for today's meeting.
Waldemar
Excellent Japanese ISO comments!
Discussion of the comment on 7.9.1:
BreakStatement:
break [no LineTerminator here] Identifier-opt ;
means:
BreakStatement:
break [no LineTerminator here] ;
break [no LineTerminator here]
Erik Arvidsson wrote:
3. Why isn't there a way to iterate over the keys?
Because then it would be a regular map, not a weak map. This is something that
only a debugger should be able to do.
Waldemar
___
es-discuss mailing list
Peter van der Zee wrote:
My vote would go to leave function as it is, if not then to use lambda or florin
and otherwise something like the above. Reserve # and @ for new syntax.
I second that.
Waldemar
___
es-discuss mailing list
Maciej Stachowiak wrote:
On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote:
Mark's restricted production idea is on target, if we think it's worth doing.
At least in C or C++, I've seen code like this:
veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName
ihab.a...@gmail.com wrote:
On Tue, Jun 1, 2010 at 6:26 PM, Waldemar Horwat walde...@google.com
mailto:walde...@google.com wrote:
I don't understand your example of how this is supposed to work in
the regular (non-accidental-aliasing) case. As you wrote in your
example, two.js
Brendan Eich wrote:
So either we lose this refactoring equivalence:
b = a[i];
b.x = 42;
assert(a[i].x === 42);
This assertion botches with Sam's proposed semantics.
Or else we lose the other equivalence, if we reify a struct-view-object
on element extraction (rvalue):
a[j] = a[i];
a[j].x =
Oliver Hunt wrote:
If b is not an alias to /a[i]/ then the code
a[i].x += 1;
Could not modify /a[i]/ itself, effectively we've created an immutable type.
That does not logically follow. See my previous message for why.
Waldemar
___
es-discuss
Brendan Eich wrote:
There's an issue with float32 -- IIRC it does not project into float64
(AKA double). All the other types (uint32, what I schematically named
u32 above, etc.) do.
What? The set of all float32's is a proper subset of the set of all float64's.
When devising scalar types for
Brendan:
To clear up something that misled me when reading the first few messages of
this struct thread:
I assume that the proposal is that:
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:u32, y:u32, z:u32,
ihab.a...@gmail.com wrote:
// one.js:
import jQuery.ajax;
module Two = load 'two.js';
// two.js:
import jQuery.ajax;
At the time that one.js was written, two.js did not contain a
reference to Drawing. Now, unbeknownst to the author of one.js,
two.js changed and now refers to
Here are my notes for today's meeting.
Waldemar
Khronos: standard-setting consortium
Khronos standards are royalty-free (any essential patents must also be
royalty-free).
We'll have a joint meeting with them on Tuesday 3PM.
Khronos categories of members: adopters and implementors.
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.
David Herman wrote:
Thinking about continuations
http://calculist.blogspot.com/2010/04/thinking-about-continuations.html
Your attempted fix for evaluating finally blocks just moved the problem
elsewhere. Since in the final expression you have A(... A(x)), you'll just end
up
David Herman wrote:
We've given this quite a bit of time, and I don't know how far we're going to
get in understanding all the details of your proposal. But I think I can
address some of my disagreements.
1) I'm skeptical whether the requirement you stated of future-proofing code for
async
David Herman wrote:
Your answers keep leaving out the definition of the function that you're calling
via `-', which is supposed to be the part that creates the requisite object
with `continueWith' etc. Examples don't do much good if they skip the part they
were supposed to illustrate!
I
Mike Samuel wrote:
That's the case right now, except that to escape a backtick one does
$\` instead of \`.
Having `\`` not do what I'd expect escaping to do truly surprised me. I
thought that this was just a bug in the grammar when I read the wiki page.
The grammar has other bugs having to
Congratulations!
ES5 was officially approved as an ECMA standard at the ECMA General Assembly
held at Google yesterday. The vote, with 2/3 required to pass, was 19 yes and
2 no, with IBM voting no due to the lack of decimal and Intel voting no because
they didn't have enough time to study
This proliferation of little function objects is one of the things that the
various class proposals are addressing.
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brian Kardell wrote:
Uh oh... Patrick looking at the same parts as me reacting the same way
(I believe older pre-5 docs also said something similar)...
When Oliver said All ES implementations are required to... I assumed
that I missed something in the new 5 docs - not that everyone just
seems to
Brian Kardell wrote:
It sounds to me like there is wide agreement in the sense that at
least the basics rules and only disagreement on the fringes...
Otherwise no one on this list in particular would be suggesting that
there is anything remotely like a de facto implementation... It
seems that at
Brendan Eich wrote:
I will stop the over-citing madness here and now :-P.
The struggle to formalize ArrayLike, which seems like a common goal for
ES the core language and for WebIDL's ES bindings, makes me want to give
an exception to the catchalls considered harmful for new interfaces
Maciej Stachowiak wrote:
Perhaps when catchalls are considered for ECMAScript, there could b a
way to encapsulate the specific pattern of index access, so you can have
magical getters and setters for all index properties (integer numbers in
range to be an array index) without having to install
are
available in Mountain View, Sunnyvale, Palo Alto, or, if you rent a car and
prefer a more urban but faraway environment, San Francisco. There are no
hotels within walking distance of the Google campus.
For questions, please email the hosts Waldemar Horwat (walde...@google.com
650-253-5868
Douglas Crockford wrote:
Waldemar Horwat wrote:
2) Do we want to permit conforming implementations to extend the JSON
grammar that they recognize? This probably could be done by
extending the syntax error extension allowance in section 16 to
include the JSON grammar. If we allow
Douglas Crockford wrote:
Waldemar Horwat wrote:
OK, so we need not discuss any new numeric types any further in
committee because it would be impossible to round-trip them through
JSON. Do we have agreement on that?
Not necessarily. What we can agree on is that new numeric types cannot
Brendan Eich wrote:
On May 14, 2009, at 6:04 PM, Waldemar Horwat wrote:
Brendan Eich wrote:
On May 14, 2009, at 1:47 PM, Waldemar Horwat wrote:
This whole thing is another nail in the coffin of generators.
Generators are the root of the troublesome longjmp's which don't
play well
This whole thing is another nail in the coffin of generators. Generators are
the root of the troublesome longjmp's which don't play well with others.
Waldemar
Brendan Eich wrote:
To make this clear with an example (thanks to Jason for some IRC
interaction):
function gen(arg) {
Allen Wirfs-Brock wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sorry, I meant the issue James raised: the property is bound and then
RangeError is thrown. Seems like error-checking should happen before
any effects are committed.
In general, it's probably
David-Sarah Hopwood wrote:
I'll repeat my argument here for convenience:
A DivisionPunctuator must be preceded by an expression.
A RegularExpressionLiteral is itself an expression.
(This assumes that the omission of RegularExpressionLiteral from
Literal is a bug.)
Therefore, for there
What are you trying to do? Exclude all scripts that use the operator?
Waldemar
David-Sarah Hopwood wrote:
Suppose that S is a Unicode string in which each character matches
ValidChar below, not containing the subsequences !, / or ]], and
not containing ( followed by a character not
If we no longer throw EvalError, we should take the class out of the body of
the spec too. It just clutters things up.
The obvious place for such obsolete things is Annex B. It contains such gems
as Date.getYear and octal digits in literals.
Waldemar
Allen Wirfs-Brock wrote:
Now that we have decided that all declarations of the identifier “eval”
are banned from strict code a related question has come up from one of
the implementers of our strict mode prototype implementation.Why
does Es3.1 still allow assignment to the identifier
Are there implementations that throw it? I thought there was at least one.
Waldemar
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich wrote:
I’ve tried various formulation of a simple statement about host
objects but I keep finding potential holes and coming back to the
conclusion that the only meaningful thing to do is to explicitly
enumerable the invariants associated with each predefined [[Class]]
value.
There is some confusion between section 7.8.5 and chapter 16 in the latest
ES3.1 draft. Section 7.8.5 states that an implementation may extend the
regular expression constructor grammar, which presumably implies that it does
not have to report all syntax errors in the ES3.1 regular expression
Here are my meeting notes from all three days of the meeting.
Waldemar
SES meeting Jan 27 2009:
ES3.1 opens up the possibility of exposing protected objects to unprotected
code and have the protected objects stay safe. Maybe not: toSource, watch (to
set watchpoints on properties),
Here are my notes on today's TC39 ES3.1 discussions. We resolved a lot of
issues, which I hope I recorded all below.
Waldemar
John and Allen want a flag date to issue s press release about a candidate
spec. Change control may be locked down after that?
Waldemar: ECMA should not be the
7: Should we replace the two instances of LineTerminator in the grammar at the
beginning of the chapter to LineTerminatorSequence? It doesn't make any
difference as far as the grammar is concerned, other than implying unwritten
expectations for counting line numbers. The downside is that
Waldemar Horwat ([EMAIL PROTECTED]
650-253-5868).
Waldemar
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Here are my preliminary comments. I haven't reviewed the entire draft yet.
Waldemar
Overall: With const missing, the changes to chapter 8 for attribute description become premature
standardization and should be cut. The problem is that these changes are likely to be incompatible with
More comments.
Waldemar
11.1.5: This means that I can override a getter with a value property or
specify two getters for the same property even in strict mode. We had agreed
that strict mode disallowed such things.
11.2.1: where identifier-name-string is a string literal containing
Mark S. Miller wrote:
The indexOf and lastIndexOf methods are new in ES3.1, and are the only
methods in the entire spec that depend on ===.
Strictly speaking that's true, but only because the switch statement is not a
method. switch statements depend on ===.
Waldemar
Mark S. Miller wrote:
11. If the [[Class]] property of /G/ is *Function*, then
1. Get the *length* property of /G/.
2. Let /L/ be Result(11a) minus the length of /A/.
What does minus mean here? Result(11a) could be anything.
Waldemar
As you noted, we can't break existing usages of var:
if (foo)
var x = 3;
As such, var statements should be considered to be substatements and allowed
anywhere. The declaration scope syntax rules would only apply to const and
function declarations (and, in the future, let).
I don't see any
Brendan Eich wrote:
Followup to discuss some open issues from the thread, evident in the
message cited below:
1. Unifying var scope and let scope at top level of a function could be
done, with tolerable restrictions: given let x at top level in a
function body, existence of formal
Eric Suen wrote:
I think top-down parser has no issue to parse following code:
function() {
}();
but this is not a valid statement because:
ExpressionStatement ::= [lookahead ! {{, function}] Expression ;
There is a good reason for that. It's because of semicolon insertion. You'd
Dave Herman wrote:
Do you see where I'm going with this? It's a pretty natural idea. The
branches of an if-statement can be in tail position because they are the
last thing produced by the if-statement. Some things like loop forms and
switch won't be able to contain tail positions because
101 - 200 of 235 matches
Mail list logo
