Common Lisp ontop of guile

Common Lisp ontop of guile

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]

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!

[-- Attachment #2: Type: text/html, Size: 2930 bytes --]

Re: Common Lisp ontop of guile

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

hi Stefan! Thanks for the reply!
Please let me share some ideas:

2014年5月20日 上午4:36于 "Stefan Israelsson Tampe" <stefan.itampe@gmail.com>写道：

>
> 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.

I see, but if someone want to do a serious hack for CL compiler on Guile, a
simple(maybe naive) mind to translate AST of CL to tree-il and pray for the
heaven is obvious insufficient. :–)
So one has to customize the backend for CL properly.

> 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.

Yes I agreed. I have to point out that we can hardly expect Guile core
provides generic solution for various languages, which means the frontend
hacker has to consider to produce better optimizer with the tools Guile
provided (CPS,DCE,CSE...). Maybe the original tools is not suit(?), and one
has to write new one.

...

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

I'm hacking on guile-lua these days, when it's done, I may have some
experiences on frontend. Lua seems relatively easier than CL situation. But
it's hard when you want it to be full compatible with the original one.

Any comments? :)

> Cheers!
>

[-- Attachment #2: Type: text/html, Size: 2168 bytes --]