I sent an email about that, but it was only an idea. I thought it would be
nice if we could work with the Clisp people. However, I can see some
barriers to actually doing that, and I don't intend to work on it any time
soon.

Noah


On Sat, Jan 12, 2013 at 3:43 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:

> On Wed, 2012-11-21 at 16:51 +0100, Stefan Israelsson Tampe wrote:
> > Hi,
> > > In terms of strategy, I think Guile’s focus should remain primarily
> > on
> > > Scheme variants, and ELisp.  Other language front-ends are of course
> > > welcome, but we must keep an eye on what the demand is.
> >
> > What about common lisp is scheme a lisp or is CL a scheme :-)
> >
>
> IIRC， someone raised the topic that emerge Clisp into Guile in 2011,
> but what's the status now?
>
> > Anyway to support CL I would think that we need to support placing
> > properties
> > on symbols, e,g. currently a symbol slot is a variable, but to
> > effectively support CL I would go for
> > /Stefan
> >
> >
> >
> > Den 21 nov 2012 14:26 skrev "Ludovic Courtès" <ludo@gnu.org>:
> >         Hi!
> >
> >         nalaginrut <nalaginrut@gmail.com> skribis:
> >
> >         > I switch to lua branch then compiled it and try, seems some
> >         bugs there,
> >         > it can't run successfully:
> >         > -------------------cut--------------------
> >         > scheme@(guile-user)> ,L lua
> >         > Happy hacking with Lua!  To switch back, type `,L scheme'.
> >         > lua@(guile-user)> x=1
> >
> >         Maybe you need a semicolon here?
> >
> >         > And I checked the code, it doen't use Guile inner LALR
> >         parser.
> >         > Anybody point me out what is the suggested parser
> >         implementation?
> >
> >         (system base lalr).
> >
> >         > And is there anyone ever evaluated the efficiency about the
> >         non-scheme
> >         > language implemented within Guile?
> >
> >         I don’t think so.  Only the Scheme and Emacs Lisp front-end
> >         are
> >         reasonably mature, anyway.
> >
> >         > Anyway, this wouldn't be a big problem, since Guile could be
> >         the
> >         > future dynamic language compiler collection, it could be
> >         optimized
> >         > later.
> >
> >         FWIW, I don’t quite buy the “dynamic language compiler
> >         collection”.
> >         Others tried this before (Parrot), with some success in terms
> >         of
> >         supported languages, but not much beyond that.
> >
> >         In terms of strategy, I think Guile’s focus should remain
> >         primarily on
> >         Scheme variants, and ELisp.  Other language front-ends are of
> >         course
> >         welcome, but we must keep an eye on what the demand is.
> >
> >         Thanks,
> >         Ludo’.
> >
>
>
>
>