guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Common Lisp ontop of guile


From: Stefan Israelsson Tampe
Subject: Common Lisp ontop of guile
Date: Mon, 19 May 2014 22:36:34 +0200

Hi, I saw on irc that nalginrut was dreaming of implementing common lisp ontop of guile
I have spent some time thinking on that and came to the following conclusions.

1. Common lisp symbolic treatment and guile's syntax system does not mix well.
2. If we want to reuse CL code we will find out that the it produces tons of tagbodies. 
This can't be directly implemented by letrecs but delimeted continuations is needed. And with those it is somemwhat fuzzy how well optimized the code will become e.g. there is a risk of slow tagbodies. On the other hand doing an implementation of CL might challange the guile hackers to produce an even better optimizer. So tagbodies is doabale and I have code that does them.
3. CL is littered with use of put and get together with symbols, these probably have to be fast in order to be usable for the common lisp code out there. But for a first try, a simple hashmap will probaly do.
4. CL symbols has a variable context and a function context, again a hashmap can be used on the symbols namespace combo.
5. The CL spec is pretty hefty but most of it should be able to be derived from a smaller subset of ideoms. I would try to find an implementation (or an early correct version of an implementation of CL) where this is a fact (matured versions tend to optimize ideoms to death and therefore many idems will be special) Ask around in CL forums for the best fit.
6. Not sure how to make the CL module system to interop with the guile system

Again if one can find a CL implementation witch is mostly written in CL, then the effort might not be too hefty.

A question is how one would treat common lisp symbols, if we would like to interoperate between scheme and CL one need to do it with symbol name mangling 
   e.g. f @ ns => f::ns

With this we may be able to write a reasonable compiler to scheme

Another possibility might be to treat symbols as vectors e.g. 
#(cl-symbol symbol ns (fslot) (vslot) (put/get-alist))

It's but ugly, but for sure the guile compiler would make sure that all symbol vectors point to the same vector hence the fslot vslot and put/get-alist is unique and can be mutated as is, then of cause there need to be some code written to be able to lookup these structures in other modules. Perhaps all symbols in a module can be put as a namespace mangled symbol guile exported as symbol e.g. g::nm for use in scheme code also a good thing with this is that ns can be a list of symbols just as in guile.

I'm sure I've mised many points but at least these thoughts might initiate a discussion.

Cheers!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]