it seems there is a bunch of existing implementations of lisp with gtk binding. so is there anyway to use them directly instead of maintaining rep and rep-gtk, which could be a heavy work when gtk updates?
On Sun, 03 May 2009, Eli Barzilay wrote: > On May 4, Chengqi(Lars) Song wrote: > > 0) extra/guile-gtk > > Guile-gtk is glue code to make the GTK+ (the Gimp Toolkit) > > accessible from Guile > > 1) clisp-gtk2: > > ANSI Common Lisp interpreter, compiler and debugger (with gtk2 > > enabled) > > 2) clfswm: > > A(nother) Common Lisp FullScreen Window Manager > > 3) stumpwm-git: > > A tiling, keyboard-driven window manager written in common lisp > > 4) cmucl: > > CMU Common Lisp. There are two CMUCL bindings to the GTk+ widget > > set. Espen Johnsen's clg binds directly to the GTk event loop via > > the CMUCL FFI (GNU LGPL). Gilbert Baumann's (older) binding uses > > a client-server model to avoid problems with mixing two event > > loops. > > You should add plt scheme to the list -- it is full of useful > libraries, has a good ffi, uses a jit to execute code relatively fast, > it's very alive and under active developement, and it's big enough > that I can't write any decent one-sentence feature list. I'm one of > the core developers, so I'll be happy to help with any needs -- like > adapting glue code or module syntax. (And in case anyone wonders, > this is not a plug I'm dropping for nothing: I've been a sawfish user > for a really long time, and one of the things that always bothered me > was the choice of a language that is "somewhere between elisp and > scheme".) > > > > I think the advantage of guile is that it's used by gimp, [...] > > No -- the gimp plan was to eventually move to guile, but this was > never done (IIRC, the reason given was that it's too big or something > like that). So it's still using a very small (and not really good) > Scheme interpreter. FWIW, I think that sawfish is in a different > place which justifies a good language: Gimp uses Scheme for writing > automated scripts but it's a C application -- whereas sawfish is > mostly written in Scheme (and with a good language, even more can move > to Scheme, making it easier to hack). > > This leads to another question that should be considered: is it better > to have a C application that embeds a Scheme interpreter or is it > better to go the other way and have a Scheme application with some > library/ies that are written in Scheme. I strongly believe that the > latter is a more sensible choice -- and was done once with the scwm > window manager (which I used before I switched to the more alive > sawfish). > > > > The advantage of clisp is that common lisp is a lot more powerful > > than scheme. but im not sure if it's a good or bad thing for > > developing sawfish. > > I could say here that PLT Scheme is far more powerful than common > lisp, but what I should really say is that any specific implementation > of either Scheme or CL is far more powerful than that. The real > advantage of CL implementations is that more is standardize -- but for > reasons that I can get to if anyone cares, that is not really a > problem, and even less so for sawfish. The disadvantage of most > common lisps is that they tend to have a "monolithic repl" approach, > which usually makes them less convenient to embed or to turn to a > distribution. > > The PLT Scheme point is that it is particularly powerful with a ton of > useful stuff. Of course this could be a problem: the installation is > pretty big -- which is fine when you want to use it, but not fine when > all you need is a window manager. The solution for this in PLT is its > ability to compile into "binaries" and/or distributions via its > command line compiler tool. A "binary" is really a copy of mzscheme > (the plt scheme core) with byte-compiled scheme code attached; and a > distribution is basically a file tree holding only the files that are > needed for an application. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life!
