Hello,
I'm considering using GUILE for an embedded language. I've seen some
negative comments regarding GUILE here without any specifics, and I'd
be very interested to hear what its problems might be.
Thanks,
David.
--
David Fenyes -- ·······@home.com
>>>>> "David" == David Fenyes <·······@flash.net> writes:
David> Hello, I'm considering using GUILE for an embedded
David> language. I've seen some negative comments regarding GUILE
David> here without any specifics, and I'd be very interested to
David> hear what its problems might be.
One thing that bothers many people is that you have to let Guile have
main(), which will then call your own internal_main() or something.
This is for garbage collection purposes.
But if you want to ask more questions, I suggest joining the Guile
mailing list; see
http://www.gnu.org/software/guile
for subscription information.
David Fenyes <·······@flash.net> writes:
>I'm considering using GUILE for an embedded language. I've seen some
>negative comments regarding GUILE here without any specifics, and I'd
>be very interested to hear what its problems might be.
Speed, especially startup time. Documentation, especially taking into
account how long they are on it. It's also not clear to me what the
exact direction is - since it took the direction away from SCM, there
didn't seem to be coming many features that justify this.
I also like the C interface of the libscheme derivates more. When I
use an embedded scheme, I use mzscheme.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) wrote in
<·············@counter.bik-gmbh.de>:
>David Fenyes <·······@flash.net> writes:
>
>>I'm considering using GUILE for an embedded language. I've seen some
>>negative comments regarding GUILE here without any specifics, and I'd
>>be very interested to hear what its problems might be.
>
>Speed, especially startup time. Documentation, especially taking into
>account how long they are on it. It's also not clear to me what the
>exact direction is - since it took the direction away from SCM, there
>didn't seem to be coming many features that justify this.
>
>I also like the C interface of the libscheme derivates more. When I
>use an embedded scheme, I use mzscheme.
>
>Martin
I agree and would also like to add that mzscheme runs on a lot more
platforms (win32, unices, Mac, Beos) than guile.
Immanuel
I've been using it a lot for a couple years, and have no serious
complaints -- the startup speed has been much improved recently,
as has the documentation. My impression is that it went through
a long period where its maintainers were actually working on
other things, but that has also changed recently. The business
about main() is not a big deal in practice, and there's a
way around it -- it will be included in guile soon, they say.
My main gripe is that there's no "real" scheme compiler, so
signal processing code is slow.
I won't say much about Guile, except that my experiences with scwm (a
window manager using Guile) were rather bad. I don't know how much of
this is Guile's fault, and how much is because they based scwm on
fvwm, rather than rewriting from scratch.
I would urge you to check out librep (http://librep.sourceforge.net/).
The window manager "Sawfish" (http://sawmill.sourceforge.net/) uses
librep, and my experiences with this are very positive.
Aside from what I said about window managers, it seems to me that
Guile is being built by a committee, and librep is mostly one very
bright guy. I'm amazed at how far librep has come in a short time,
and how little Guile has improved over the years that I've been
watching it.
- Sam
Centuries ago, Nostradamus foresaw a time when Sam Falkner would say:
>I won't say much about Guile, except that my experiences with scwm (a
>window manager using Guile) were rather bad. I don't know how much of
>this is Guile's fault, and how much is because they based scwm on
>fvwm, rather than rewriting from scratch.
Probably a fair bit of the latter; I'll not draw conclusions on the
former...
>I would urge you to check out librep (http://librep.sourceforge.net/).
>
>The window manager "Sawfish" (http://sawmill.sourceforge.net/) uses
>librep, and my experiences with this are very positive.
>
>Aside from what I said about window managers, it seems to me that
>Guile is being built by a committee, and librep is mostly one very
>bright guy. I'm amazed at how far librep has come in a short time,
>and how little Guile has improved over the years that I've been
>watching it.
Guile suffered from the problem of nobody working on it for quite a
while; that period appears to be over. Mind you, there is _still_ not
the "systems integration" done on making it _easy_ to transform it
into a compiled form (e.g. - via "Hobbit") so it is _EASY_ to compile
Guile code into fast machine code, for all that people have suggested
that this _could_ be done.
In the long run, librep is likely to suffer from that same problem,
that you're restricted to "however fast the interpreter is," with
little recourse to allow making it faster by compiling to machine
language.
--
·····@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/lsf.html>
"A LISP programmer knows the value of everything, but the cost of
nothing." -- Alan Perlis
········@news.hex.net (Christopher Browne) writes:
> Centuries ago, Nostradamus foresaw a time when Sam Falkner would say:
> >I won't say much about Guile, except that my experiences with scwm (a
> >window manager using Guile) were rather bad. I don't know how much of
> >this is Guile's fault, and how much is because they based scwm on
> >fvwm, rather than rewriting from scratch.
>
> Probably a fair bit of the latter; I'll not draw conclusions on the
> former...
>
> >I would urge you to check out librep (http://librep.sourceforge.net/).
> >
> >The window manager "Sawfish" (http://sawmill.sourceforge.net/) uses
> >librep, and my experiences with this are very positive.
> >
> >Aside from what I said about window managers, it seems to me that
> >Guile is being built by a committee, and librep is mostly one very
> >bright guy. I'm amazed at how far librep has come in a short time,
> >and how little Guile has improved over the years that I've been
> >watching it.
>
> Guile suffered from the problem of nobody working on it for quite a
> while; that period appears to be over.
#+flame
I beg to differ. Guile suffered from the "let's build yet another
Scheme interpreter while staying clear from anything Common Lispish as
possible." syndrome :)
Cheers
--
Marco Antoniotti ===========================================
Marco Antoniotti <·······@parades.rm.cnr.it> writes:
> I beg to differ. Guile suffered from the "let's build yet another
> Scheme interpreter while staying clear from anything Common Lispish as
> possible." syndrome :)
Wrong. GOOPS is very CLOS-like.
-Brett.
Centuries ago, Nostradamus foresaw a time when Brett Viren would say:
>Marco Antoniotti <·······@parades.rm.cnr.it> writes:
>> I beg to differ. Guile suffered from the "let's build yet another
>> Scheme interpreter while staying clear from anything Common Lispish as
>> possible." syndrome :)
>
>Wrong. GOOPS is very CLOS-like.
But it's taken a lot of years for it to get deployed. And it is not
part of the "standard" Guile install yet.
--
·····@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/linux.html>
"[In 'Doctor' mode], I spent a good ten minutes telling Emacs what I
thought of it. (The response was, 'Perhaps you could try to be less
abusive.')" -- Matt Welsh
········@knuth.brownes.org (Christopher Browne) writes:
> Centuries ago, Nostradamus foresaw a time when Brett Viren would say:
> >Marco Antoniotti <·······@parades.rm.cnr.it> writes:
> >> I beg to differ. Guile suffered from the "let's build yet another
> >> Scheme interpreter while staying clear from anything Common Lispish as
> >> possible." syndrome :)
> >
> >Wrong. GOOPS is very CLOS-like.
>
> But it's taken a lot of years for it to get deployed. And it is not
> part of the "standard" Guile install yet.
With the guile 1.5 (which might be called 2.0) release it will be. It
(goops itself ) is presently at version 0.9 and is quite workable.
So, next release of guile will have goops built in, as well as Jim's
environments proposal implemented, better GC and other improvements as
well.
From conversations I have had with people working on guile, the major
obstacle has not been that it's "yet another scheme interpretor" but
that SCM, upon which it is based is something that mere mortals have
problems understanding, which has lead to difficulties extending it.
SCM is quite fast and is full of hacks (the good kind), but not
everyone is an Aubrey Jaffers.
That said, guile has picked up steam in the last 6 months with alot of
stuff coming together that has been languishing for a year or more.
--
Craig Brozefsky <·····@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
From: Christian Lynbech
Subject: Re: Comments on GUILE for embedding?
Date:
Message-ID: <ofg0pp2chj.fsf@chl.tbit.dk>
>>>>> "Brett" == Brett Viren <······@superk.physics.sunysb.edu> writes:
Brett> Marco Antoniotti <·······@parades.rm.cnr.it> writes:
>> I beg to differ. Guile suffered from the "let's build yet another
>> Scheme interpreter while staying clear from anything Common Lispish as
>> possible." syndrome :)
Brett> Wrong. GOOPS is very CLOS-like.
However there has been some heated discussions in the past on the
mailing as to how usefull a rolemodel CL is.
The basic GOOPS is slowly deviating from the CLOS way of specifying
things, but no more than there are still a compability module.
---------------------------+--------------------------------------------------
Christian Lynbech | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J
Fax: +45 8675 6881 | email: ···@ericssontelebit.com
Phone: +45 8675 6828 | web: www.ericssontelebit.com
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)