Refining the formalism of the spec

[codehag]

This is an ongoing effort by the TC39 Editors cc @michaelficarra

This issue can be a coordination point if we can help in any way?

[jmdyck]

"Machine readable" is a spectrum.

• One could claim that simply having the spec in a file (rather than just as a printed document) makes it machine readable.
• The transition from an MS Word document to a text-based document made the spec more machine readable.
• And the use of an HTML-like syntax (rather than, say, RTF) makes it more machine readable.

So I don't think it's a question of 'achieving' machine readability, but just a question of how to make the spec more machine readable than it already is -- how to make it more amenable to automated processing. Which then depends on the kind of processing you want to perform.

[jmdyck]

Here are some broad questions that TC39 might want to answer via automated processing of the spec (or a proposed new version of the spec):

• Does it conform to the editorial conventions?
• Is it logically consistent?
• Is it correct? That is, does it convey the intent of TC39?

(And in each case, if the answer is no, then how/where does it fail?)

For the question of correctness, I think you need to compare it to some other statement of intent, which would mainly be test262. I.e., does the spec, when 'run' on the tests, give the expected results?

Implementers and JS developers would probably have other questions that could be answered by automated processing.

[michaelficarra]

@codehag I think you have a bit of a misunderstanding. There is no standing goal to achieve "machine readability". I agree with @jmdyck that it is a spectrum and different machine consumers have different needs. You could argue that ecma262 is machine readable today given esmeta exists and works. Our only official stance is that we have a list of consumers we consider when making editorial decisions which includes machine consumers. We will continue trying to make it a better document for machine consumers, just as we continue to make it a better document for all of our other consumers, weighing tradeoffs as we come to them.

[codehag]

Thanks for the clarifications @jmdyck and @michaelficarra.

@michaelficarra I should have given some context for this issue: Yesterday people expressed how difficult it was to find out what TG5 had discussed or worked on, or what researchers could help with. This is a valid criticism, I'm trying to capture possible discussions and past discussions in the issues to help facilitate collaboration. Embarrasingly, at the moment my brain leaks information continuously. Sorry about this. The title was trying to capture what was discussed in https://github.com/tc39/tg5/blob/main/meetings/2024-06-26.md. Do you have suggestions on how we can capture it better? Maybe I should have just used your title there: Editors' work on refining the formalism of the spec

Do we already have a writeup on the work you presented to TG5 @michaelficarra ? it was really interesting and capturing that through some form of documentation

[Jack-Works]

engine262, a JS engine that implemented the spec step by step, adopted TypeScript last year. It has the potential to check spec bugs by the type checker. I think that is also a step toward the "machine-readable" spec.

[jmdyck]

If it helps detect+correct a spec bug, then that makes the spec better (more correct), but I don't think I'd say it makes the spec more machine readable.

---

In general, the spec's algorithms aren't written in a way to facilitate static type-checking. Does Typescript raise lots of spurious warnings when applied to engine262 code? (Alternatively, do you have to @ts-ignore lots of things?)