Cassie Jones [Thu, 27 Feb 2020 17:27:37 +0000 (18:27 +0100)]
Add support for globals which don't get captured
Lots of top-level definitions don't need to be copied into every
closure, because they're constant for the whole program. Global
variables are never inserted into the upvars entry, so they won't be
copied into closures.
This also adds "builtin" names that are inserted into the initial
context for arithmetic and comparisons. Booleans have to be builtin due
to being returned by the comparisons, but they're still intended to be
implemented via church encoding.
Cassie Jones [Thu, 27 Feb 2020 16:58:19 +0000 (17:58 +0100)]
Parse S-expressions into the abstract syntax tree
While doing this, we handle name resolution and "upvar" captures. The
name resolution context "Env" forms a stack that has a reference to the
outer environment at each level. A new level is pushed at each lambda
that's introduced. The environment includes a list of "upvars" that have
to be copied into the closure, which is updated every time a variable
lookup finds the variable in an outer environment instead of the local
environment. This process has to use a RefCell because you can't make
the lifetimes work out with a chain of mutable references.
The parsing aside from that environment stack is relatively
straightforward parsing.
Cassie Jones [Thu, 27 Feb 2020 13:19:40 +0000 (14:19 +0100)]
An s-expression parser and an example program
This is intended to be a slightly fancier lambda calculus with
arithmetic support. The way I've written the example here suggests not
making conditionals a builtin, and instead just using church encodings.
This will probably be bad for displaying data purposes? I'm not sure how
I want to handle I/O. Maybe do an ML and put impure I/O in here?