-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editorial: misc fixes #1636
Editorial: misc fixes #1636
Conversation
Wow I can't believe we missed these. |
Added 3 commits relating to the merge of PR #1376. |
@@ -19962,7 +19962,7 @@ <h1>Runtime Semantics: ClassDefinitionEvaluation</h1> | |||
<pre><code class="javascript">constructor() {}</code></pre> | |||
using the syntactic grammar with the goal symbol |MethodDefinition[~Yield, ~Await]|. | |||
1. Set the running execution context's LexicalEnvironment to _classScope_. | |||
1. Let _constructorInfo_ be DefineMethod of _constructor_ with arguments _proto_ and _constructorParent_. | |||
1. Let _constructorInfo_ be ! DefineMethod of _constructor_ with arguments _proto_ and _constructorParent_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the ?/! feels awkward with this form - meaning where it doesn't look like a JS function invocation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, ...
- The spec already has 45 occurrences of this form.
- It looks like you yourself were the first to add it: 9405a43 (lines 7060 and 7062)
- If PR Add aoid and update calling conventions for directed operations #955 goes through, such invocations could be changed to a more javascript-y form anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True enough :-) it still looks weird to me.
spec.html
Outdated
@@ -24768,7 +24768,7 @@ <h1>Object.prototype.valueOf ( )</h1> | |||
<emu-alg> | |||
1. Return ? ToObject(*this* value). | |||
</emu-alg> | |||
<p>This function is the <dfn>%ObjProto_valueOf%</dfn> intrinsic object.</p> | |||
<p>This function is the <dfn>%Object.prototype.valueOf%</dfn> intrinsic object.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please revert this; as long as %ObjProto_valueOf%
and similar exists in the table, these prose comments referencing it should remain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean references within <dfn>
? I addressed that in the commit message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean prose that mentions them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, but why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire line isn't needed unless %ObjProto_valueOf%
exists, because it's already implied by being reachable from %Object%
. As such, these lines should remain untouched, until a future PR removes both them and the legacy intrinsics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! I had wondered about the tautology of X.Y is the intrinsic object %X.Y%
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But wait, in f1b22ef, you changed a bunch of prose-y references from old-style to new-style. Is there something different about them, or was that just a mistake? And do you want me to revert them back to old-style too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed all of them except the ones that were in these bullet lists, defining the objects at their creation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about line 24664 (is the intrinsic object <dfn>%Object.prototype%</dfn>
)
and line 38776 (is the intrinsic object <dfn>%AsyncFunction.prototype%</dfn>
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops, looks like i mistakenly changed those. sorry for the confusion
spec.html
Outdated
@@ -25819,7 +25819,7 @@ <h1>Number.prototype</h1> | |||
<h1>Properties of the Number Prototype Object</h1> | |||
<p>The Number prototype object:</p> | |||
<ul> | |||
<li>is the intrinsic object <dfn>%NumberPrototype%</dfn>.</li> | |||
<li>is the intrinsic object <dfn>%Number.prototype%</dfn>.</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, and throughout.
Force-pushed the branch. The only new things are the last two commits, which should resolve recent discussions here with @ljharb. |
Commit f1b22ef (tc39#1376) changed lots of intrinsic-names from old-style to new-style. But these two should have stayed old-style, so switch them back. (See tc39#1636 (comment))
Added a commit to fix a step-reference in Annex B. |
If nothing else, I'd really appreciate the first commit being merged. That one missing dot is very annoying: I'm forever inserting it to get the algorithm to parse, and then removing it so that I don't commit it on some completely unrelated branch. |
In PR tc39#1571: https://github.com/tc39/ecma262/pull/1571/files#diff-3540caefa502006d8a33cb1385720803L19940 removed the step "Assert: _constructorInfo_ is not an abrupt completion." but didn't insert the equivalent "!" on the previous line. https://github.com/tc39/ecma262/pull/1571/files#diff-3540caefa502006d8a33cb1385720803L23362 removed a ReturnIfAbrupt step, but didn't insert the equivalent '?' in the previous line. --- Commit f1b22ef (tc39#1376) changed 2 occurrences of "%AsyncIteratorPrototype% to "%AsyncIterator.prototype% but the latter assumes a well-known intrinsic named "%AsyncIterator%", which doesn't exist. This commit changes them back. --- Commit f1b22ef (tc39#1376) changed lots of intrinsic-names from old-style to new-style. But these two should have stayed old-style, so switch them back. (See tc39#1636 (comment))
In Editorial commit f1b22ef (tc39#1376): - "%<var>NativeError</var>Prototype%" changed to "%NativeErrorPrototype%", which doesn't make sense, because there's no such intrinsic. - "%<var>TypedArray</var>Prototype%" changed to "%TypedArrayPrototype%", which would be a change in semantics, which shouldn't happen in an Editorial commit. So these changes were presumably mistakes.
Commit ea16790 inserted a step, pushing the Annex B 'insertion point' from step 28 to step 29.
Thanks for the merge! |
.. re PR #1571
... and PR #1376.