January 8, 2021
Development Plan for Lisp Software
I've being studying source code in Fool's Lisp by Jonathan Lee written in 1989. It implements reference counting GC in a really smart way. The data types are constructed from a type struct which contains fields for the reference count, and for allocating and deallocating cells. GC is performed simply by by gc_start and gc_end which to me sort of simulates a manual intervention in GC. The problem with reference counting GC is the complexity of working around circular loops which require adding more code or intelligence to GC routines.
I plan to change the data structures in rtlisp to make it possible to deallocate a cell as the reference count go to zero instead of navigating through long lists to deallocate a single cell as it's done in rtlisp now.
December 20, 2020
Mxlisp is being reworked by eliminating some code thereby
simplifying the tightly couple software. Xlisp is wonderfully
written code, but I can't untangle the mixing of error handling
with "regular" code. Besides this there's the problem of
keeping track of continuations.
Mxlisp and mlisp will be merged together and it's principle features will be moved into a new mlisp. I consider the most important feature to be the foreign function interface, ffi. The primary ffi feature in nlist will be the "load-library" function. From previous tests, mlisp procedures which are compiled into native c-code runs as fast or faster than the compiled (fasl) code in Chez and Chicken scheme. This may eliminates the need to keep the VM modules in mxlisp and mlisp if I can figure out how to cleanly create builtin procedures which are compiled into c-object code within mlisp.
I haven't completed the implementation of escape continuations, ie., call-ec, in nlisp. Adding escape continuations should not slow down the context switching processes for nlisp too much. nlisp also uses Common Lisp like return and goto. I'll know more when I can test this in the future.
I still don't know how to implement full continuations in nlisp. This is really complex to me, and makes me appreciate the fine job David Betz did in developing this code.