Added a readme that may simplify trying to use the code. Also note that I removed all of the ``pseudoevaluation'' hackery; so that contrived explanation is now null.
On Sat, Dec 7, 2013 at 12:57 AM, Aaron Burrow <burrows.l...@gmail.com>wrote: > I've been working on an implementation of boot.c in common lisp for the > past few weeks; my code now correctly generates eval.s. > > You can find the code here https://github.com/burrows-labs/below-the-top. > > I had been considering for some time that lisp evaluation could be broken > down into an abstract transformation machine. Each stage composing on the > results of the previous stage until finally execution stops after doing the > evaluation transformation. Each stage has it's own set of semantics > pertaining to the different data types. ie, expansion treats a macro > differently than the reader. I implemented boot.c using this model. > > The code still needs a bath and it's very slow; largely because it's using > an assoc list and string= to lookup symbols. > > In order to run the code, you will also need this file > https://github.com/burrows-labs/lisp/blob/master/repl-utils.lisp. And > you will have to make these changes to the maru code > https://gist.github.com/burrows-labs/1f2edcdd92271a9c8ef7. My > implementation uses a graph for environments and this doesn't play well > with what maru expects for current-environment(...) (being the global > environment usually). I also didn't spend time trying to get *globals* to > work; so you have to use _global-environment(...). > > The c implementation of maru uses encode(...); which changes the semantics > of doing lookups in ``operators'' and ``forms'' (global variables) as > emit.l expects symbols to already have been substituted for fixed and expr. > > > Implementing quote(...) and set(...) nicely proved to be challenging. I > introduced the ``pseudoexpansion'' transformer to handle with set(...). > Here (set (that other) x) we want to expand set(...) after it's arguments > are expanded (because ``that'' might be a macro). We could explicitly > expand the arguments in maru-primitive-set; currently we use > ``pseudoexpansion''. > > During ``pseudoexpansion'' we know that all other expansions have occurred. > > I never came up with a satisfactory solution for quote; currently the > expansion transformer has to use a conditional for fixed leads in order to > prevent the expansion of quote args. > > _lead_ is what the implementation calls the first form in an sexpression. > > _args_ are the other forms. > > There are more than 100 tests at the bottom of 'metalang.lisp' that may > help in understanding how the code works. I also kept a list of notes > about the original boot.c that you can find here > https://gist.github.com/burrows-labs/7369854. > > the ``='' operator is broke; it gives incorrect results for things that > aren't strings, symbols and numbers. but it works well enough to run the > compiler. > > Generalizing the processing of the sexpressions into the transformers > model was pretty straightforward for the most part. But note that > *forwarding-symbol* is a bit of a hack. Because I want to deal with each > type of object in it's particular handler for each stage of execution (and > not just do everything in the symbol handler); some combinations of > transformer and data type require me to return the symbol instead of the > thing it's binded to. In particular if I'm doing an expansion and I get > forwarded to an expr, it needs to know what symbol it's binded to (instead > of replacing the symbol with the expression object as we would during > evaluation). > > maru is a pretty ecosystem; the simplicity of the multimethod > implementation speaks for itself. >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
