Skip to content

migrate from yaml-ast-parser -> yaml package#63

Merged
cowboyd merged 2 commits intomainfrom
modern-yaml-parser
Jan 23, 2023
Merged

migrate from yaml-ast-parser -> yaml package#63
cowboyd merged 2 commits intomainfrom
modern-yaml-parser

Conversation

@cowboyd
Copy link
Copy Markdown
Member

@cowboyd cowboyd commented Jan 23, 2023

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: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:

(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)

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)`
@cowboyd cowboyd merged commit 4b011ea into main Jan 23, 2023
@cowboyd cowboyd deleted the modern-yaml-parser branch January 23, 2023 21:04
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