This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: [Q] (newbie here) Guile as an extention language.
- To: e dot sirola at finecoinvestimenti dot it
- Subject: Re: [Q] (newbie here) Guile as an extention language.
- From: Clark McGrew <mcgrew at ale dot physics dot sunysb dot edu>
- Date: Tue, 27 Jun 2000 09:55:26 -0400
- CC: guile at sourceware dot cygnus dot com
- References: <NDBBILFJIMJCCIMHMLPOMECECBAA.e.sirola@finecoinvestimenti.it>
- Reply-to: clark dot mcgrew at sunysb dot edu
Hi,
You'll probably get better answers from people that are more
connected with development.
GUILE is really the kernel of the beginnings of the GNU extension
language. It's very much a work in progress. The intention (as on
the web page) is to use the guile evaluator to process any number of
languages, sort of like the gcc backend is used for any number of
compiled languages. Unfortunately, that particular goal is a long way
in the future.
I'm not familiar with the perl/python internals, but the guile core is
quite small. It's also a pretty good implementation of an extremely
clean language (scheme) so it's got a well defined semantics. In
addition guile plays nice with other compiled languages (I've used C,
C++, and F77). There's currently a little bit of bloat in libguile,
but that will be taken care of as the library is broken in the
separate modules.
My personal take is that a decision was made that the elisp core was
not aging gracefully and a replacement with a small footprint was
needed. Guile fit the bill. This is a *completely* uneducated
opinion, but otherwise I'd've expected the current elisp kernel as the
GNU extension language. There are plans and some work being done to
get emacs running off the guile core (using elisp)
Anyway, This is one outsider's answer to "Why Guile?" so please don't
take it very seriously.
Clark
BTW: Guile isn't ready to compete with perl or python as a general
purpose scripting language, but it's already a good implementation of
scheme. It's getting better very quickly now. As far as I can tell
there are only two big chunks of unfinished work (the object system,
and an improved module system) before the core is finished. Both of
these pieces exist, but have not been folded into the development
tree. When they are the guile "user" libraries should develop very
quickly.