On 2018-09-04 12:02 PM, Allen Wirfs-Brock wrote:
At one point, early in the development of ES6 the draft spec. had a
[[OriginalDescriptor]] field (that may not be the actual name I used) in
internal PropertyDescrptors that carried along a reference to the original
descriptor object from
On 2018-05-28 02:09 PM, T.J. Crowder wrote:
Am I right that Symbols started out as "private Name objects" then over time
their name was changed, they became primitives,
As far as the spec is concerned...
Symbols were introduced in draft 12 of ES6.
They were defined as a kind of exotic
On 17-08-19 01:34 PM, T.J. Crowder wrote:
An ECMAScript *language type* corresponds to values that are directly
manipulated by an ECMAScript programmer using the ECMAScript language. The
ECMAScript language types are Undefined, Null, Boolean, String, Symbol,
Number, and Object. An *ECMAScript
On 17-07-26 07:32 AM, T.J. Crowder wrote:
Second, the general: What's the significance of the indentation? Some
productions are indented more than others, and I can't see meaning in it.
No significance, just a styling thing.
See https://github.com/tc39/ecma262/issues/956
-Michael
On 17-04-09 05:13 PM, Darien Valentine wrote:
I am curious about this lexical production, because if I understand
correctly, it seems to imply either backtracking or a lookahead that isn’t
made explicit.
Yes, depending on your parsing technique.
..., a naive match will be made for
On 17-02-07 06:02 PM, Waldemar Horwat wrote:
Lookahead restrictions fit very well into an LR(1) engine [...]
it's directly tied into the generation of the automaton states. Each
automaton state contains a collection of possible places in the
expansions of grammar rules that the state can
On 17-02-06 07:32 PM, Waldemar Horwat wrote:
On 02/04/2017 07:20, Michael Dyck wrote:
On 17-02-03 05:32 PM, Waldemar Horwat wrote:
On 02/03/2017 08:17, Michael Dyck wrote:
On 17-02-02 06:23 PM, Waldemar Horwat wrote:
Lookahead restrictions fit very well into an LR(1) engine
Again: Great
On 17-02-03 05:32 PM, Waldemar Horwat wrote:
On 02/03/2017 08:17, Michael Dyck wrote:
On 17-02-02 06:23 PM, Waldemar Horwat wrote:
Lookahead restrictions fit very well into an LR(1) engine
Again: Great, but how? E.g., do you pre-process the grammar, modify the
construction of the automaton
On 17-02-02 06:56 PM, Dmitry Soshnikov wrote:
Just to double-check, by "parametrized productions" you mean the
`No` extra productions?
See the 'Grammar Notation' section of ES6+, at the paragraph beginning
"A production may be parameterized by a subscripted annotation".
They were introduced
On 17-02-02 06:23 PM, Waldemar Horwat wrote:
Lookahead restrictions fit very well into an LR(1) engine
Again: Great, but how? E.g., do you pre-process the grammar, modify the
construction of the automaton, and/or modify the operation of the parser?
as long as they're limited to only one
On 17-01-31 02:17 PM, Dmitry Soshnikov wrote:
The spec is a formal language definition (including for syntactic grammar).
(Well, the extent to which the spec is formal is debatable. The grammar is
the most formal part of it, but that's true of most programming language
definitions.)
It
On 17-01-30 06:20 PM, Dmitry Soshnikov wrote:
On Mon, Jan 30, 2017 at 2:22 PM, Michael Dyck <jmd...@ibiblio.org
<mailto:jmd...@ibiblio.org>> wrote:
1. Using "No" productions.
The problem with this approach is that, in general, a
On 17-01-30 03:00 PM, Dmitry Soshnikov wrote:
On Mon, Jan 30, 2017 at 9:26 AM, Michael Dyck <jmd...@ibiblio.org
<mailto:jmd...@ibiblio.org>> wrote:
On 17-01-30 12:15 AM, Dmitry Soshnikov wrote:
As mentioned above, there are two ways to handle lookahead
On 17-01-30 12:15 AM, Dmitry Soshnikov wrote:
As mentioned above, there are two ways to handle lookahead restrictions in
LR-parser:
1. Using "No" productions. This unfortunately may double number
of productions in some sub-grammar. E.g. to handle Block vs. ObjectLiteral
in ECMAScript, one
On 17-01-23 08:24 PM, Waldemar Horwat wrote:
On 01/11/2017 10:28, Michael Dyck wrote:
If so, I'm wondering how lookahead-restrictions (e.g., [lookahead
I have an implementation of the parser with a few extensions to the LR
grammar, including support for ... lookahead restrictions
On 17-01-11 09:09 PM, Isiah Meadows wrote:
Heuristically, I doubt it's even context-free at this point, considering the
concept and widespread prevalence of early errors now. I suspect it's mildly
context-sensitive (maybe tree-adjoining?), but I'm no formal language expert
here.
I think the
In the past, it has been said (usually by Brendan Eich) that TC39 intends
that the ECMAScript grammar be LR(1). Is that still the case? (I'm not so
much asking about the "1", but more about the "LR".)
If so, I'm wondering how lookahead-restrictions (e.g., [lookahead terminals]) fit into the LR
On 16-09-23 10:24 AM, Felix Kling wrote:
I read these paragraphs over and over again ;) Maybe I just need someone to
explain it to me in different words.
So to apply these to my case:
- `ResolveBinding` is an *"abstract operation"* so it returns a completion
record, whose value is a
Email notifications from bugs.ecmascript.org appear to be broken.
The last email msg I received from bugzilla-dae...@bugs.ecmascript.org
was on 2015-07-20. Starting 2015-07-27, there have been changes to 32 bugs
that I should have received notice of. So it seems like the breakage
occurred in
On 15-08-11 11:47 AM, Allen Wirfs-Brock wrote:
On Aug 10, 2015, at 6:03 PM, Michael Dyck wrote:
While converting the HTML spec into ecmarkup, I found roughly 100
glitches (depending on what and how you count),
Have you checked them against http://ecma-international.org/ecma-262/6.0
On 15-08-10 03:14 PM, Allen Wirfs-Brock wrote:
There is also now a bugzilla component for ticketing rendering bugs in
the HTML version of the ES6 spec:
https://bugs.ecmascript.org/buglist.cgi?product=ECMA-262%20Edition%206component=html%20rendering%20issuesresolution=---
I encourage anybody who
In the minutes for July 28, Rick Waldron wrote:
## 9 Tooling Updates
Ecmarkup (Emu)
- [...]
- Michael Dyck now maintaining es-spec-html, working on high-fidelity emu output
- [...]
To clarify...
Back in mid-April, I volunteered to maintain the HTML version of the ES
spec, taking over from
On 15-06-17 12:46 PM, Allen Wirfs-Brock wrote:
Ecma international has announced that its General Assembly has approved
ECMA-262-6 /The ECMAScript 2015 Language Specification/ as an Ecma standard
http://www.ecma-international.org/news/index.html
Congrats!
The official document is now
Can someone explain to me why the spec needs NextJob?
Consider this alternative:
-- Replace every invocation of 'NextJob' with 'Return'.
-- Introduce a top-level abstract operation for them to return *to*:
1. Call Initialization().
2. Repeat:
a-h. [steps 2-9 of NextJob]
i.
On 15-05-18 03:09 PM, Allen Wirfs-Brock wrote:
On May 18, 2015, at 10:17 AM, Michael Dyck wrote:
As far as I can see, this has the same semantics as the current spec [..], but
it's simpler, since:
(a) it doesn't need to introduce NextJob [...]
(b) it doesn't need to introduce Job
On 15-04-16 11:23 AM, Jason Orendorff wrote:
[...] I will not be creating the unofficial HTML version of the spec
anymore once ES2015 is final.
If you're interested in maintaining the HTML version, let me know! [...]
I'm interested.
[...]
But there is one more job.
Back in 2013, I
On 15-04-08 12:19 PM, Domenic Denicola wrote:
This was discussed briefly at the previous meeting, perhaps un-minuted.
The meeting notes for Jan 29th have a section where ecmarkup/down is
introduced and discussed somewhat, but there's no decision regarding its use.
The basic plan is to
In the March 24 meeting notes (e.g.,
https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-03/mar-24.md ),
there's the line:
DD: once the great tooling revolution arrives, there will be a live
GitHub version of the spec that implementers consult.
but I don't see any discussion
What happens to all the unresolved 6th edition bugs when 6th edition is
finalized? (There's currently about 66 in the Confirmed state.) Do they
all get transferred over to 7th edition? Or do they stay where they are,
hoping for resolution in an ES6.1 (or at least an ES6 errata), but perhaps
just
On 15-03-11 04:39 PM, Allen Wirfs-Brock wrote:
On Mar 11, 2015, at 12:31 PM, Michael Dyck wrote:
What happens to all the unresolved 6th edition bugs when 6th edition is
finalized?
They will all be either resolved or transferred to ES7
Good to hear.
-Michael
On 15-03-09 04:10 AM, Coolwust wrote:
I know a production may be parameterized by suffixing the nonterminal
symbol, my question is what is the meaning of the parameter [Yield], [In]?
To figure out the 'meaning' of a particular parameter, look at all the
places where that parameter is used as a
On 15-03-06 06:46 AM, raul mihaila wrote:
Do sentences like it's a syntax error if the LexicallyDeclaredNames of
StatementList contains any duplicate entries (section 15.1.1) refer to the
result of applying the LexicallyDeclaredNames rule for a production
alternative in which StatementList is
In the 2015-01-29 meeting notes, in the section on ecmarkup,
this exchange is noted:
BT: I believe Allen would like to continue using Word
DH: No, we want to get away from that
AWB: ISO requires the document to be submitted in Word
I have it on good authority that JTC 1's IT Task Force,
On 14-05-22 05:58 PM, Allen Wirfs-Brock wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#may_22_2014_draft_rev_25
In bugs.ecmascript.org, the Draft for 6th Edition Product needs a Version
for new rev.
-Michael
___
For the past couple of days, when I create or modify a bug on
bugs.ecmascript.org, my browser doesn't get a response. I know
the requests are being received, because when I check via another
tab, the creation or modification has happened. (I *do* get a
response for all my other requests.)
Is
On 14-04-06 11:41 AM, Allen Wirfs-Brock wrote:
The April 5, 2014 ECMAScript 6 Draft Specification (Rev23) is now
available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#april_5_2014_draft_rev_23
I just noticed something odd.
If you open up the PDFs for rev22 and
On 14-02-15 07:44 PM, C. Scott Ananian wrote:
On Feb 15, 2014 9:47 AM, Brendan Eich wrote:
When I'm in a bad mood, I call it VisualCobol. It's painfully
low-level and verbose, yet hard to verify. Let's hope that the JSCert
work will help, and Allen has been common'ing subroutines. Whatever we
On 14-02-07 03:15 PM, Allen Wirfs-Brock wrote:
The Yield parameter selects whether or not yield is treated as an
identifier or as an operator symbol. yield is only treated as an
operator if the yield parameter is present.
Yup, got that.
The GeneratorParameter parameter, when present, tags
I've more-or-less finished composing my comments on rev22, and I find that,
even after eliminating comments that have already been made, I'm still left
with about 280.
Now, there's no way I'm going to create 280 bugs at bugs.ecmascript.org.
I'd go crazy with all the copying and pasting. Even if
On 14-02-10 08:37 AM, Allen Wirfs-Brock wrote:
I'd suggest grouping all minor editorial bugs by chapter. That's how
I'll process them.
So, just to be clear, a chapter is what the spec itself (usually) calls a
clause? (I.e., the main body of the spec has 26 of them.) If so, that
means I'll
On 14-02-10 11:53 AM, Allen Wirfs-Brock wrote:
sure, add the complete list to bug 2428
Done!
Thanks for all the great reports,
You're welcome. It's nice to hear they're appreciated.
-Michael
___
es-discuss mailing list
es-discuss@mozilla.org
When I take the ECMAScript grammar and expand its abbreviations as outlined
in section 5.1.5, I get a grammar with lots of unreachable nonterminals
(i.e., symbols that can't appear in any sentential form derived from Script
or Module).
For instance, consider StrictFormalParameters. With its
Could someone give it a nudge?
-Michael
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 13-08-23 08:51 AM, Allen Wirfs-Brock wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft
When I view the PDFs in Adobe Reader, most of the body text is rendered
in Adobe Sans MM, which is what it substitutes when it can't locate the
original
Could someone with the necessary permissions on bugs.ecmascript.org
please add a Rev 16 version to the Draft for 6th Edition product?
See https://bugs.ecmascript.org/show_bug.cgi?id=1580
Thanks,
-Michael
___
es-discuss mailing list
Looking at the ES6 spec draft, I've drawn the following conclusions
about Completion Records. Can someone confirm?
If [[type]] is 'normal', 'return', or 'throw',
[[target]] must be 'empty' (can't be an identifier).
Moreover, if [[type]] is 'return' or 'throw',
[[value]] must be a
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
程劭非 wrote:
Though it's a little too long since this discussion, I've tried Allen's
idea in my parser and still find conflicting.
Consider the following rules:
PropertyAssignment :
IdentifierName PropertyName ( ) { FunctionBody }
PropertyAssignment :
PropertyName :
Brendan Eich wrote:
Don't forget method definition shorthand syntax, if the next token is
(. Then the method is named get, of course.
Yup. Like I said, I was ignoring the effect of other productions.
(That's what the OP appeared to be doing too.)
-Michael
Allen Wirfs-Brock wrote:
The Nov. 22, 2012 draft of the ES6 specificaiotn is now
at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
Clicking pdf with change markup only for this revision
yields Not Found.
-Michael
___
es-discuss
David Herman wrote:
- The spec is not in any machine-readable form, meaning it's neither
testable nor formally verifiable in any way.
I'm working on transforming the spec into a machine-friendly form.
(That's how I come up with most of the bugs I submit.) Eventually, it
could be testable. I
David Herman wrote:
On Nov 3, 2012, at 12:16 AM, Michael Dyck jmd...@ibiblio.org wrote:
David Herman wrote:
- The spec is not in any machine-readable form, meaning it's neither
testable nor formally verifiable in any way.
I'm working on transforming the spec into a machine-friendly form
bugs.ecmascript.org appears to be down.
(100% packet loss when attempting to ping it.)
Any idea when it'll be back up?
-Michael
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Norbert Lindenberg wrote:
Up and running again.
Thanks!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock wrote:
Another concern is that the entire grammar really needs to be revalidated
after major changes. The last time the grammar was validated was for
ES3 (1999) and we don't currently have the tools or people in place to
validate it again (any volunteers out there??).
What
Allen Wirfs-Brock wrote:
I'm again considering creating a line-by-line translation of the ES6
spec algorithms into an executable evaluator of parse trees.
Cool. So my work might help you do the translation programmatically.
this would be a non-normative translation of the spec. that could
According to
http://wiki.ecmascript.org/doku.php?id=harmony:harmony
goal #2 of Harmony is:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
Is there much activity toward this goal? The current ES6 drafts are
using mostly the same formalism
Brendan Eich wrote:
On Oct 26, 2011, at 12:08 PM, Michael Dyck wrote:
According to
http://wiki.ecmascript.org/doku.php?id=harmony:harmony
goal #2 of Harmony is:
Switch to a testable specification, ideally
a definitional interpreter hosted mostly in ES5.
Is there much activity toward
Rick Waldron wrote:
Michael,
It took me a while to find them the first time I looked, but they are
downloadable here:
http://hg.ecmascript.org/tests/test262/
Instructions here:
http://wiki.ecmascript.org/doku.php?id=test262:command
Yup, I'm aware of the test262 project -- I even submitted
Allen Wirfs-Brock wrote:
I'm personally finding it harder to find things in the current draft.
To fix this I've been experimenting with several different organizations
and I would like some feedback on the alternative I've come up with.
I think the third version is the most readable. The
Allen Wirfs-Brock wrote:
The doc version of the latest stable draft is always posted
at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
I can also start to post a docx version if there are people that want
them.
Yes, please.
Currently, to get something I can deal with,
Mark S. Miller wrote:
On Wed, Oct 27, 2010 at 7:24 PM, Michael Dyck jmd...@ibiblio.org wrote:
So I'm asking here: what's the best means (and form) for giving feedback
on the ES5 spec to TC39?
This lack of explanation is a serious problem. Thanks for bringing it to
our attention
62 matches
Mail list logo
