Thank you for your interest in contributing to open source software projects (“Projects”) made available by Authors of GG (“Authors”). This Individual Contributor License Agreement (“Agreement”) sets out the terms governing any source code, object code, bug fixes, configuration changes, tools, specifications, documentation, data, materials, feedback, information or other works of authorship that you submit or have submitted, in any form and in any manner, to Authors in respect of any of the Projects (collectively “Contributions”). If you have any questions respecting this Agreement, please
Starting with @snowyu’s proposal I infer some design principles:
- This language is designed to be easy to render using existing Markdown, YAML, and syntax highlighters.
- The language should break out to TypeScript that is evaluated in the scope of a global object that represents all of the play state.
- The Markdown script is a Markdown subset that uses inline backtick expressions to break out to an annotation language that carry semantics.
- The annotation language embeds the TypeScript grammar for evaluating expressions.
My iteration on this design adds some detail:
- We use a Markdown variant that forbids arbitrary HTML, adds semantics to list item notation, and uses backticks for annotations.
Disclaimer: This text is exclusively focused on the existing capabilities of the language, and does not weight into additional capabilities like wasm, or virtual modules, or compartments. Those can be discussed later on.
The bare minimum mechanism to create a module graph that matches ESM requires few main pieces:
- A portable (serializable) structure that represents the source text of the module.
ModuleSourcemust be portable across processes and across realms. - A realm based
Modulethat closes over aModuleSource.
OlderNewer