Skip to content

Add support for extracting spec algorithms in JSON format#312

Merged
jhnaldo merged 8 commits into
es-meta:devfrom
tontonialberto:main
Oct 28, 2025
Merged

Add support for extracting spec algorithms in JSON format#312
jhnaldo merged 8 commits into
es-meta:devfrom
tontonialberto:main

Conversation

@tontonialberto
Copy link
Copy Markdown
Contributor

Hi,

As previously discussed with @jhnaldo during ECOOP 2025 / PLSS, I've implemented a JSON protocol for ECMA-262 algorithms extracted by ESMeta, so that users can analyze their Abstract Syntax Trees in a standardized format:

  • Each algorithm is dumped in a separate file within the EXTRACT_LOG_DIR/algos_json directory
  • The AST structure follows an uppercase-lowercase structure (uppercase for node names, lowercase for property names)
  • Correctly serializes number literals: supports positive and negative zero, positive and negative infinity. I'm mentioning this because, by default, circe serializes Infinity values as null

The JSON protocol recursively serializes algorithms and steps. Typing information is currently represented in a stringified format - I'm working on adding support for types in JSON format.

You can serialize the algorithms in JSON format by simply executing esmeta extract -extract:log.

Alberto Tontoni added 4 commits September 22, 2025 12:41
- Dump each algorithm in a separate file within the EXTRACT_LOG_DIR/algos_json directory
- The AST structure follows an uppercase-lowercase structure (uppercase for node names, lowercase for property names)
- Correctly serializes number literals: supports positive and negative zero, positive and negative infinity
@jhnaldo jhnaldo changed the base branch from main to dev October 27, 2025 06:31
@jhnaldo
Copy link
Copy Markdown
Contributor

jhnaldo commented Oct 28, 2025

Thank you for submitting this PR. I've refactored the implementation using the helper functions deriveEncoderWithType and deriveDecoderWithType. These allow us to consistently generate encoders and decoders that leverage the type name for both encoding and decoding, ensuring the encoding results are identical to the original implementation.

The only difference compared to the original implementation is in how we handle Double values, where I've reused the existing Double implementation to maintain standard behavior:

  • Double.PositiveInfinity: Serializes to the String "Infinity"
  • Double.NegativeInfinity: Serializes to the String "-Infinity"
  • Double.NaN: Serializes to the String "NaN"
  • Other Double values: Serializes as a standard Number

This keeps the serialization in line with standard JSON representations for these exceptional numeric values.
I've merged the changes, and they look great. Feel free to let me know if you have any questions.

@jhnaldo jhnaldo merged commit d0abba2 into es-meta:dev Oct 28, 2025
3 checks passed
@jhnaldo jhnaldo added new feature Implements a new feature area:spec Related to specifications labels Jan 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:spec Related to specifications new feature Implements a new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants