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