[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile Lua
Stefan Israelsson Tampe
Re: Guile Lua
Wed, 21 Nov 2012 16:51:03 +0100
> 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 :-)
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
Den 21 nov 2012 14:26 skrev "Ludovic Courtès" <address@hidden
nalaginrut <address@hidden> skribis:
> I switch to lua branch then compiled it and try, seems some bugs there,
> it can't run successfully:
> 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
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.
Re: Guile Lua, Ian Price, 2012/11/19