Re: the future of Guile

[Mike Gran]

> On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:

> > Pre-answer to all: the most important thing is to make clear
> > what are  the priorities.  With a  "language for extensions"
> > (LFE)   there  are  certain   priorities,  with   a  "Scheme
> > implementation"  (SI) there are  others. I  fear that  if no
> > choice is made Guile will be wiped out by other Schemes.

As far as being an LFE, 1.8.x has been a big improvement over 1.6.
The API is much cleaner when wrapping stuff by hand. 

> From: Roland Orre <address@hidden>

> Today, however, I find that there are nearly no extension
> libraries available for guile. As a shell scripting language
> I prefer python because it has a very simple and clean
> shell interface. To extend my applications beyond real number
> crunching with e.g. graphical interphases (currently working
> with xlib...) I feel a limitation and have more and more often
> looked upon python where a lot of libraries are available for
> GUI, database and you name it.

One problem here is that there does need to be a richer library
that is official and downloadable right from
www.gnu.org/software/guile.  Unit test, documentation, 
cgi, http, sql, md5, utf8, xml, and perhaps pickle.

Much has been done (GEE, Guile-lib, guile-gtk, all of TTN), 
but, each has its own packaging scheme, documentation
scheme.  None of them are released in a coordinated manner 
with the Guile releases themselves. 

This goes back to the packaging problem.  After I've written a program, 
I'd like to give it away for others to use.  Giving code away in a scripting 
language should be easy.  It isn't easy here. 

First, dependencies on the many libraries are
difficult to coordinate.

Second, most non-trivial scripts require the whole of the configure, 
make, make install, LD_LIBRARY_PATH, %load-path overhead.

Where is the analog of a Java jar file?

Apologies if my rant has drifted off topic.

Thanks,

Mike Gran