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