Re: [Q] (newbie here) Guile as an extention language.

[Jonathan Bartlett <johnnyb at wolfram dot com>]

There was a big flame war on this subject (I think it was called the TCL
war, when RMS first decided to create this project - its in the manual).
Anyway, the superiorities:

1) Data and programs share a common form (your program is just a list of
lists that are evaluated)

2) Closures are a more generic and flexible way of implementing just about
any style of programming (closures are treated very clearly in Scheme and
the Art of Programming).  Programs can be written very quickly and
concisely in Scheme.  I once saw a chess program with an AI (not a very
good one, but good enough) written in scheme in under 15 pages of code.

3) Like most other interpretted languages, there are no true pointers,
so memory management is taken care of.

4) It is easy to write programs that call guile from C and vice-versa
(Perl is infinitely more complicated).

5) Very small and easy-to-learn syntax (however, special forms can drive
you up a wall)

6) In guile you can build language translators which convert programs from
other languages into scheme, so you have automatic support for other
languages

Problems with scheme/guile

1) Not as flexible as perl - this is both a benefit and a problem.  Perl
has a syntactic form for almost anything you commonly do.  In fact, it has
several forms.  So, it's more flexible, but that can cause problems.  Many
times I have written perl code where I _thought_ I knew what the code was
doing, but I was wrong, being confused by exactly how the syntax works.
In scheme, the syntax isn't as flexible, but you always know what it's
doing.  Obviously, Perl was written by a linguist, and scheme by a
computer scientist

2) In the scheme implementation, it uses garbage collection, rather than
refcounts.  This has some benefits - memory management is easier because
you don't have to do it - but it can cause problems as well.  One problem
is that you have to modify the programs "main" function.  This limits the
number of programs you can really write bindings for.  For example, the
Apache group wouldn't care if I wrote a mod_scheme module if it was using
refcounts, but I think they would laugh out loud if I submitted an apache
patch that ran gh_enter as void main() if mod_scheme was enabled.  This is
true with many extensible programs - guile has to be built in to begin
with, and cannot simply be a plugin.

3) It hasn't been widely adopted.  Although guile was meant as _the_ GNU
extension language, there aren't an overwhelming number of programs using
it (there some significant ones, but, like GIMP doesn't, and it uses
scheme even)

Anyway, those are my thoughts.

Jon

On Tue, 27 Jun 2000, Enrico Sirola wrote:

> Hello,
> I know a bit of lisp (just enough to configure emacs), but i have a good
> grasp in C and Perl/Python programming and I am now intrested in writing
> programs extentions with interpreted languages. I saw guile is
> "the" gnu extentions language, and i suppose it's been choosed becouse it's
> intrinsecally superior than perl/python, but i can't see this intrinsic
> advantage (that's probably becouse of my poor lisp/scheme programming
> skill).
> Can any1 please explain the technical reasons leading to this choice? I know
> this is probably a question a million people asked already, so any pointer
> to FAQs or documents on the net would be fine too.
> If you think i'm off topic here, please let me know it.
> Thanks a lot in advance, (and sorry for my broken english)
> Enrico Sirola
> 
> --
> 	Enrico Sirola
> 	Quantitative Analyst, FIN-ECO Investimenti SGR
> 	Via A. Boito 10, I-20100 Milan, Italy
> 	mailto:e.sirola@finecoinvestimenti.it
> 
>