Migrate to ecmarkup #135
Merged
Migrate to ecmarkup #135
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the first step to revamp this repo: [ecmarkup](https://github.com/tc39/ecmarkup) is TC39's official tool for specifying syntax and semantics for ECMAScript. I proposed that we should adopt it because it has several favorabilities than the current approach (`README.md` + a `gh-pages` website living in the `websitescript` branch): 1. The resultant `index.html` has a similar looks and feels with the official ECMA-262 spec. 2. It uses [Grammarkdown](https://github.com/rbuckton/grammarkdown) which is not only convenient to write but more importantly, can enforce the grammar to be more formal. 3. It provides links to ECMA-262 out of the box (closed facebook#112). Furthurmore, I can use `<ins>` to make "extension" points explicit. One possible concern it that it'll make this too like a ECMAScript proposal, but I think we mediated by opting-out from the "stage-N proposal" heading, and by explicitly calling out our intention in the "Introduction" section. In addition, - Link to JXON is updated since the original link no more existed. - Parser and Transpiler section is dropped from the "spec" website. - Facebook, Inc. is updated to Meta Platform, Inc everywhere. Once this is merged, we can switch to `main` to host Github Pages.
Jack-Works
reviewed
Feb 23, 2022
Comment on lines
+71
to
+73
| <emu-note> | ||
| names of |JSXOpeningElement| and |JSXClosingElement| should match. | ||
| </emu-note> |
There was a problem hiding this comment.
Maybe more formal?
<emu-clause>
<h1>Static Semantics: Early Errors</h1>
<emu-grammar>JSXOpeningElement JSXChildren? JSXClosingElement</emu-grammar>
<ul>
<li>It is a Syntax Error if the JSXElementName of |JSXOpeningElement| does not have the same source text to JSXElementName of |JSXClosingElement|.</li>
</ul>
</emu-clause>There was a problem hiding this comment.
Yup I've been thinking of that, but wanted to see if people like this direction first.
Being able to conveniently use other ECMA-262 specification devices is definitely why this change is appealing. There are probably more static semantics hidden from implementations other than this alone.
Thanks for the review! PRs are welcomed once this is merged 😉
|
Hey @Jack-Works this has been merged. Would you be interested in submitting a PR for the Early Errors? You may use the "Editorial" tag for that. |
This was referenced Feb 25, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This is the first step to revamp this repo: ecmarkup is TC39's official tool for specifying syntax and semantics for ECMAScript. I proposed that we should adopt it because it has several favorabilities than the current approach (
README.md+ agh-pageswebsite living in thewebsitescriptbranch):index.htmlhas a similar looks and feels with the official ECMA-262 spec.<ins>to make "extension" points explicit.One possible concern is that it makes this spec a bit like a ECMAScript proposal, but I think we mediate it by opting-out from the "stage-N proposal" heading, and by explicitly calling out our intention in the "Introduction" section.
In addition,
Once this is merged, we can switch to
mainto host Github Pages.Test Plan
open
index.html