Slib frustrations

[John Daschbach <d3h486@wd19518.emsl.pnl.gov>]

I have been struggling with guile off and on for some time.  Every so
often I give it a try and usually wind up frustrated.  When I do I go
back to SCM and wonder why I wasted my time.  SCM is stable, fast, and
very well documented.  I've embedded it in a multiprocess server,
written C extensions, compiled it with hobbit, used dynamic loading of
compiled extenstions, and used it as a portable scripting language
across a number of platforms.

My latest frustration seems rather simple, but I've wasted enough time
on it that I can't see continuing with guile for the near future.
(more on this later).

Before I found the FAQ I tried to load "slib.scm".  (this is using
guile 1.3 and guile-gtk-0.16).  

[d3h486@wd19518 Guile]$ guile
guile> (load "slib")
ERROR: In procedure primitive-load in expression (primitive-load name):
ERROR: No such file or directory: "slib"
ABORT: (system-error)

Type "(backtrace)" to get more information.
guile> (%search-load-path "slib")
"/usr/local/share/guile/site/slib.scm"
guile> (version)
"1.3"
guile> 


The news files states:

*** (primitive-load FILENAME :optional CASE-INSENSITIVE-P SHARP)
uses %seach-load-path to find a file named FILENAME, and loads it if
it finds it.  If it can't read FILENAME for any reason, it throws an
error.

Clearly this in not true!

Then in the FAQ I found that one should use:

(use-modules (ice-9 slib))
(require 'format)
ERROR: In procedure gsubr-apply in expression (@apply fun (apply:nconc2last args)):
ERROR: No such file or directory: "/usr/local/share/guile/site/slib/mklibcat"
ABORT: (system-error)
guile> (system "ls /usr/local/share/guile/site/slib/mklib*")
/usr/local/share/guile/site/slib/mklibcat.scm
0
guile> 



You can require a number of slib modules, but many give the error
above.  

It looks like 'load is again broken, this time not trying the
extension '.scm' even though %load-extension has the value ".scm".  So
cp mklibcat.scm mklibcat works, but then slib writes slibcat in
../../site rather than ../slib/.

With effort one can work around these problems, but it seems that
there are always many of these with each guile release.  SCM on the
other hand has been stable and robust for a long time.

I have been following guile for many years and the idea and effort are
noble.  But the implementation of the releases is not a shining
example of GNU software.  I have been using GNU/FSF software for
around 15 years and guile has the worst documentation of any important
piece of GNU software I can remember.  One of the main reasons that
GNU software became so widely used is because it was well documented.
At one point the guile mailing list had a discussion of the various
attributes of different documentation systems, but this was a classic
can't see the forest for the trees case.  Compare trying to use guile
to downloading SCM and Slib and installed them with their info files,
then getting the hyperlinked R4RS.texi and R5RS.texi files.  In
minutes you have a robust, complete, well documented scheme system.
To use guile you have to spend a great deal of time looking through
and grepping the source files to find the non-R?S functions which are
not documented.  

Many of us don't have the time to be digging around in the source to
figure out how to use something.  If you want to build a tool that
only the dedicated few will use that's fine, but then it's wrong to
consider it the universal GNU scripting language.  I like software and
I can and do read a lot of source, but even then guile is near my
limit of being unusable.  For most others it is a non-starter.  Some
very bright people have put a lot of thought and work into guile but
if they don't want to see guile used as a classic example of the
failure of "open source" software it needs to have documentation.

I'll give it another try here with guile-gtk (my current motivation,
otherwise back to SCM and STk).  I'd like to see it work.

-John