Re: Guile Lua

[Noah Lavine]

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 <address@hidden> 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" <address@hidden>:
>         Hi!
>
>         nalaginrut <address@hidden> 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’.
>