Skip to content
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

Parsing updated ecma262 intrinsic notation #897

Closed
ljharb opened this issue Jun 17, 2020 · 8 comments · Fixed by #898
Closed

Parsing updated ecma262 intrinsic notation #897

ljharb opened this issue Jun 17, 2020 · 8 comments · Fixed by #898

Comments

@ljharb
Copy link
Contributor

ljharb commented Jun 17, 2020

Hi!

In the ecma262 spec, we've added a new intrinsic notation form that will avoid unbounded growth of our list of intrinsics.

Specifically, things like %ArrayPrototype% and %ObjProto_valueOf% should now be represented as %Array.prototype% and %Object.prototype.valueOf%, respectively.

Our intention is to delete the "legacy" forms entirely in favor of the dotted forms. I wanted to file a PR on https://github.com/whatwg/html, but then realized I might need to file one on https://github.com/heycam/webidl/blob/master/index.bs#L88-L110 first (I filed w3c/webidl2.js#480 before this, and was directed here).

I'm happy to do the work to update spec text (and for HTML, I have a branch prepared already), but I doubt I'm qualified to do the work here. Could someone help give me pointers as to what the next steps should be?

In particular, one approach that occurred to me (that I could handle!) would be to add to the current "hardcoded legacy intrinsics mentioned in HTML" the list of "hardcoded dotted intrinsics mentioned in HTML". That seems simplest, but has the downside (one which already exists now) that a PR would still have to be made here to support autolinking a new intrinsic. The ideal approach (which perhaps could be made later) would be one that figures out from any %A.b% which section it should link to.

@annevk
Copy link
Member

annevk commented Jun 18, 2020

Search & replace should work here and in HTML and should not break anything. Though I'm not sure where they should link now?

The one loss here is that now it's no longer clear for implementers looking at ECMAScript which of these they need to support and instead they'll also have to look at IDL and HTML. This was discussed in tc39/ecma262#1105 (comment) and the idea there was to create abstract algorithms for where algorithms needed to be shared and intrinsics for when you need identity. Is that still a thing that's being considered?

@domenic
Copy link
Member

domenic commented Jun 18, 2020

I'm happy to do the work to update spec text (and for HTML, I have a branch prepared already), but I doubt I'm qualified to do the work here. Could someone help give me pointers as to what the next steps should be?

I don't quite understand the concern. What's more difficult about the IDL spec than the HTML spec? They're pretty analogous, with HTML's dependencies section being replaced by a structured metadata block in https://github.com/heycam/webidl/blob/9208c17edcfb2ee6eaebc6663d3e3155b3091a34/index.bs#L88-L96

@ljharb
Copy link
Contributor Author

ljharb commented Jun 18, 2020

@domenic one question i have: this repo contains "review_drafts" which use the legacy intrinsic style. should i update those too, or leave them alone?

@annevk the links go to the same places.

The one loss here is that now it's no longer clear for implementers looking at ECMAScript which of these they need to support and instead they'll also have to look at IDL and HTML.

I'm a bit confused by this; if an implementor is implementing a web browser, they'd have to do that anyways.

@domenic
Copy link
Member

domenic commented Jun 18, 2020

one question i have: this repo contains "review_drafts" which use the legacy intrinsic style. should i update those too, or leave them alone?

You're probably talking about the HTML repo? Those should stay unchanged.

@ljharb
Copy link
Contributor Author

ljharb commented Jun 18, 2020

ok thanks, i'll make the PR for this repo first and we can go from there :-) hopefully it's straightforward and i'm just being overly cautious by asking first.

@domenic
Copy link
Member

domenic commented Jun 18, 2020

Awesome. Thank you for the proactive work on this.

domenic pushed a commit that referenced this issue Jun 18, 2020
Follows tc39/ecma262#1376, and prevents problems
in the future when the non-dotted forms are deleted.

Closes #897.
@annevk
Copy link
Member

annevk commented Jun 22, 2020

@ljharb consider an implementer of a JS engine who wants to make it suitable for embedding in various hosts, but doesn't want to read through all the various standards applicable to each of the hosts.

@ljharb
Copy link
Contributor Author

ljharb commented Jun 22, 2020

Such an implementer would likely then need to optimistically cache all originals as potential intrinsics, yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants