You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)`
0 commit comments