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

Expression parser #464

Merged
merged 9 commits into from
Jul 7, 2022
Merged

Expression parser #464

merged 9 commits into from
Jul 7, 2022

Conversation

bakkot
Copy link
Contributor

@bakkot bakkot commented Jul 5, 2022

This adds a barebones parser for algorithm steps, recognizing calls, SDO invocations, records, and lists. It is invoked downstream of the biblio being built, which means it can differentiate List of _bar_ (which is not an SDO invocation) from SDO of _bar_ (which is).

The parser is much less sophisticated than the ones in ecmaspeak-py or esmeta. On the other hand, it's also much less specialized to the current spec text, so hopefully will not require updates as often.

The new parser is used to

  • ensure parentheses are balanced and so on
  • check that everything being called is defined (with a hardcoded list of exceptions, see below)
  • check that AOs and SDOs are invoked with the appropriate number of arguments
  • check that record field names are not duplicated within a record
  • fix the super gross post-render walking we were previously doing to check that AOs returning completion records were invoked appropriately, which also lets us get more precise location information for those errors

I've checked this on 262 and 402 (which pass without error) as well as proposal-temporal (which has a few genuine bugs this catches).

It also incidentally adds AO kinds ("syntax-directed operation", "host-defined abstract operation", etc) to the biblio. This is not a breaking change because the new type allows the kind to be undefined.


Unfortunately I've had to hardcode the names of certain operations which are invoked without being defined as operations, namely

  • thisTimeValue
  • thisStringValue
  • thisBigIntValue
  • thisNumberValue
  • thisSymbolValue
  • thisBooleanValue
  • toUppercase
  • toLowercase
  • 𝔽

The thisXValue ones are a weird thing we do where we define an AO without giving it its own clause, represented by source text like

The abstract operation <dfn id="thistimevalue" aoid="thisTimeValue" oldids="sec-thistimevalue">thisTimeValue</dfn> takes argument _value_. It performs the following steps when called:

We should get rid of these. (Also note that aoid on dfn doesn't do anything.)

toUppercase and toLowercase are invoking Unicode algorithms (see e.g. step 5 of Canonicalize). Not sure what to do about those - maybe those names should be written as `code`?

and friends just need to be defined with emu-eqn and then they can be removed from the hardcoded list; I'll make that change once tc39/ecma262#2810 lands.


Depends on tc39/ecmarkdown#92.

src/Spec.ts Outdated
}
pointer = pointer.parentElement;
const expressionVisitor = (expr: Expr, path: PathItem[]) => {
// console.log(require('util').inspect(expr, { depth: Infinity }));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// console.log(require('util').inspect(expr, { depth: Infinity }));

src/Spec.ts Outdated
nodeRelativeColumn: column,
});
} else {
// console.log(require('util').inspect(item, { depth: Infinity}));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// console.log(require('util').inspect(item, { depth: Infinity}));

@bakkot bakkot merged commit ba16c25 into main Jul 7, 2022
@bakkot bakkot deleted the expr-parser branch July 7, 2022 02:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants