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" <l...@gnu.org>: > Hi! > > nalaginrut <nalagin...@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’. >
