migrate from yaml-ast-parser -> yaml package#63
Merged
Conversation
The module we were using the parse strings into yaml syntax trees was not maintained, and had an awkward API. This meant that implementing new features which dependend on YAML serialization and deserialization were destined to be difficult. This includes implementing the print function (#51) which is on the hot path for the first iteration of an executable program. This uses the `npm:yaml` module (https://github.com/eemeli/yaml) as the basis for converting strings into yaml AST. To do this, it uses a "read" function which does a 1:1 mapping of yaml ast values to PlatformScript values. the `read()` operation does not do anything beyond this. So, for example, `read("$a-ref")` will be a `PSString`, rather than a `PSRef`. There is a `recognize()` operation that converts the "literal platformscript" value into one that contains references, functions, and templates. The "evaluation pipeline" now looks like this: `pipe(read, recognize, eval)` Mostly this change is limited to the `read`, however it does have some small implications for the higher level apis because now references are "recognized", not read directly, and so a reference value is not a JavaScript string, but rather a `PSString`. The same applies for function definitions. We now store the `head` of the function as a reference to the `PSString` that gave rise to it. So, for example, in the lambda: ```yaml (x)=>: Hello %(x) ``` The `head` is the `PSString` `(x)=>` > 💡When we have macros, we will probably insert that after `recognize`, but > before `eval`. e.g. `pipe(read, recognize, macroexpand, eval)`
taras
approved these changes
Jan 23, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The module we were using the parse strings into yaml syntax trees was not maintained, and had an awkward API. This meant that implementing new features which dependend on YAML serialization and deserialization were destined to be difficult. This includes implementing the print function (#51) which is on the hot path for the first iteration of an executable program.
Approach
This uses the
npm:yamlmodule (https://github.com/eemeli/yaml) as the basis for converting strings into yaml AST. To do this, it uses a "read" function which does a 1:1 mapping of yaml ast values to PlatformScript values. theread()operation does not do anything beyond this. So, for example,read("$a-ref")will be aPSString, rather than aPSRef.There is a
recognize()operation that converts the "literal platformscript" value into one that contains references, functions, and templates. The "evaluation pipeline" now looks like this:pipe(read, recognize, eval)Mostly this change is limited to the
read, however it does have some small implications for the higher level apis because now references are "recognized", not read directly, and so a reference value is not a JavaScript string, but rather aPSString. The same applies for function definitions. We now store theheadof the function as a reference to thePSStringthat gave rise to it. So, for example, in the lambda:The
headis thePSString(x)=>pipe(read, recognize, macroexpand, eval)