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

references missing from references list #929

Open
michaelficarra opened this Issue Jun 11, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@michaelficarra
Member

michaelficarra commented Jun 11, 2017

Some static/runtime semantics functions have no references listed but are referenced elsewhere in the spec. An example is CatchClauseEvaluation. But most of the functions in 13.15 show 0 references.

Relatedly, the reference to the Catch production within CatchClauseEvaluation is not listed in the Catch references list. It appears Ctrl-F is still necessary to ensure you haven't missed any references.

@bterlson

This comment has been minimized.

Show comment
Hide comment
@bterlson

bterlson Jun 13, 2017

Member

I could go through and add aoids to syntax-directed operations happen to have have a single specialization but I'd rather solve polymorphism more generally. See: bterlson/ecmarkup#116.

Member

bterlson commented Jun 13, 2017

I could go through and add aoids to syntax-directed operations happen to have have a single specialization but I'd rather solve polymorphism more generally. See: bterlson/ecmarkup#116.

@littledan

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Jun 15, 2017

Member

Tacking on an editorial suggestion: I think most these polymorphic internal algorithms would be easier to read if they were grouped together, more "pattern matching style" than the current "object oriented style". Leaving out Runtime Semantics: Evaluation and Static Semantics: Early Errors, and maybe a couple others, though. This would solve the tooling problem (if the aoids are also added).

Member

littledan commented Jun 15, 2017

Tacking on an editorial suggestion: I think most these polymorphic internal algorithms would be easier to read if they were grouped together, more "pattern matching style" than the current "object oriented style". Leaving out Runtime Semantics: Evaluation and Static Semantics: Early Errors, and maybe a couple others, though. This would solve the tooling problem (if the aoids are also added).

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