guile-devel
[Top][All Lists]
Advanced

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

Re: Guile Lua


From: Nala Ginrut
Subject: Re: Guile Lua
Date: Sat, 12 Jan 2013 16:43:46 +0800

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





reply via email to

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