> 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 <[EMAIL PROTECTED]> > 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 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
