In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk "Jeff Dalton" writes:
> Perhaps you should look at some Lisps that can be linked into C
> programs. Elk and libscheme, for instance. There are problems
> with just writing your own functions in C. For instance, there's
> no source notation for symbols. You can call a lookup procedure
> (e.g. symbol("abc"), but that repeats the lookup cost for every
> reference. Another example: no closures.
This is the reason I'm planning to write a special compiler for
writing Lisp interpreters in C. I might also add closures, if I
can figure out how to do it, and if I decide it's worth it. I'll
only use it for re-writing my own Lisp interpreter, but who knows?
I might like it enough to go further.
> That Lisps are written in C suggests that there are solutions
> to these programs, but the code must be written in a somewhat
> awkward and limited way. A Lisp interpreter written in C
> might have a table of all the symbols it needs, and if you
> took that approach you'd have to extend the table every time
> you wrote a function that referred to a new symbol.
The solution I used for the symbol problem you've described was
to use a global variable for each symbol used by the interpreter.
For example, sy_lambda for "lambda". I then defined sy_symbol as
a macro that expands into an index into a global array of pointers
to the actual symbol objects. That made the GC easier.
> (The table would typically be an array of pointers to symbol
> structs and the indexes might be ints. You'd #define indexes
> that were more meaningful, or maybe use an enumeration.)
With my compiler, I could use a global symbol table and the
compiler could then create the code to build the table. I'm
planning to do something similar with the dispatch table for
special forms. At the moment, I have to maintain it by hand.
--
"Internet? What's that?" -- Simon "CompuServe" Bates
http://cyber.sfgate.com/examiner/people/surfer.html