This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: non-hobbitable code



> Hobbit currently only compiles R4RS (with some rare expections
> involving mutual tail recursion and force).
> 
>     Klaus> pity because uncompiled pint is very slow (on my 8MB
>     Klaus> snail).  Will that stuff get worked on in future?
> 
> In the near future, no. I think that an optimized hobbit targeted to
> R4RS will be more useful than a catch-all compiler.

I think that's too bad.  Since Hobbit targets Guile, I think it would
be much more useful if Hobbit accepted the same language that the
Guile interpreter does.  If that language is unstable at the moment,
that might be a good reason to put off working on the compiler
immediately, but that doesn't mean it wouldn't be nice to track it in
the long run.

> I would recommend to split an application to be compiled in
> 2 parts:
> 1) a compilable R4RS part (with defmacros)
> 2) an interpreted part with all bells and whistles specific to Guile

One of the problems at hand cannot be solved this way.  Hobbit doesn't
handle keywords, which are rather difficult to modularize out.
optargs.scm uses keywords, and will soon be part of Guile proper.  I
expect it to be widely used.

I hope you'll consider extending Hobbit to handle keywords, at least.