Re: [fonc] maru bootstrap implementation in common lisp
hey aworld : a is associated with aidsyndrome immune et helthier is miru with nonhypocrytical rguments will live here while egphilippov is ietfetco's user : http://egphilippov.info/vpri.org/fonc/znc/common/zanac zanac ~ fonc? is mara of the universe ok? ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] maru bootstrap implementation in common lisp
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 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 [email protected] http://vpri.org/mailman/listinfo/fonc
[fonc] maru bootstrap implementation in common lisp
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 [email protected] http://vpri.org/mailman/listinfo/fonc
