Re: Guile Impressions

[Martin Grabmueller]

> From: John Fitzgerald <address@hidden>
> Date: Tue, 8 May 2001 10:13:54 +1200

First of all, thank you for your input.

> I have been lurking around the periphery of Guile for about a year
> now.  I have used it to extend programs, to write programs and to
> glue libraries together.  Guile is an excellent choice for the tasks
> in which I have employed it.  I would not wish to expose my
> applications' users to any of the main alternatives: TCL, Perl or
> Python.  But my use of it is hindered by a number of issues.  I
> raise these here in the hope that you can either enlighten me or I
> can give you pause for thought.

I will try, but be prepared to take my writings with a dash of salt.
I only recently started to work on Guile actively, and there are
possibly still some misunderstandings on my side, but with the help of
others, those issues will clear up.

> I'm aware that the issue of documentation is starting to be
> addressed.  This has been my main concern.  It appears to me to be
> fragmented and mainly consists of a texinfo reference and sundry
> introductory papers.  The reference is far from complete and info as
> a documentation tool is frustrating for a non-emacs person to
> navigate.  What is sorely lacking, though, is a guide to Guile; a
> document which explains not what each function, procedure or data
> structure does (that's the references job) but rather how, where,
> when and why to do things in certain ways (to foster understanding).
> If I wish to use Guile in my applications, then I need to be aware
> of the design decisions I need to make.

As I see it, I think that the Reference Manual should include some
documentation you want to see.  Every section describing some aspect
of Guile should start out with a description of the concepts involved,
and how and when these concepts apply to a particular problem.
Unfortunately, we (I?) have only managed to work on the Scheme part of
the Manual yet, and the part on Embedding and Extending is still quite
rough.

Do you think that the Reference Manual is not the place for such
information, or is it only the missing documentation you are disturbed
by?

> Until yesterday, I thought that the gh_ interface was the way to go.
> But it now appears that we would be better off using the scm_
> interface.  I have to admit to being confused, both by the apparent
> change of emphasis and by the seemingly ad hoc nature of the scm_
> interface (made worse by documentation issues).

Ad hoc?  Personally, I think that the SCM interface is quite nice once
you get used to it.  Maybe it's the lack of documentation again?

> Personally, I would appreciate a clear statement of direction from
> wiser heads than I in regard to which is the interface to use into
> the future.  If it is the scm_ interface, then it seems some work is
> required in consolidating and documenting it.

Hm.  A `clear statement' has not been reached yet by the
developers/maintainers, though I am not sure myself where the actual
opinions differ, and where we need to reach consensus.

> Another of my concerns has recently been addressed in the form of safe
> environments.  Opening up an application in the way that providing it with
> Guile as an extension language allows often carries with it the requirement
> to limit what the user can do within those extensions.

Have you been successful using safe modules?  If not, what have been
the problems?

> That Guile is addressing this is excellent, but it feds into the
> bigger picture of modules.  I keep seeing disclaimers about the
> module system being revamped and that we shouldn't rely on the
> current mechanism remaining.  The provision of modules is fairly
> core, I would have thought, to the entire structure of Guile
> applications.  I feel that a robust, stable and well documented
> module system needs to be put in place ahead of the facilities and
> features that could benefit from it.  I know the "new module
> mechanism" continues to be discussed, but it seems to me to be being
> discussed somewhat half-heartedly and not actually moving forward.

I hope this has been commented on sufficiently by thi already.

> My preferred platform is Unix, but I'm presently working with MS-Windows.
> Guile is easy to install and use in the Linux environment, but definitely
> not so on MS-Windows.  This is not a Guile failing but it would be useful if
> the stable releases were accompanied by a pre-compiled implementation for
> MS-Windows.  Guile is too valuable a tool for me not to try and use it
> whenever it's applicable.

Some time ago, I wanted to add a bunch patches to Guile which make
compiling Guile under Windows possible, even with the dreaded M$VC.  I
got distracted too many times, mainly because I can't test such
patches myself, and partly because there is simply no fun for me with
this job.  Sorry.  But I hope to pick that up some day again.
Promised.  Hopefully.  Maybe.  Hmm.  If someone here is willing to
work on this, I can send a patch against guile-1.4, which would
probably need some work, and only results in an incomplete port
(mainly missing POSIX procedures).

> Coming as I do from a procedural language background, I need to
> translate the Scheme terminology to those I already know.  Sometimes
> I do find this difficult.  (I still have no idea what fluids are all
> about.)  I would be one who'd appreciate a slightly less Scheme
> terminology ridden descriptions of some things.  So if you could
> bear this in mind, I'm sure Guile would become a friendlier place to
> some.  (And yes, I do realise this is a problem with me, not Scheme
> or Guile.)

Is this addressing mailing list language or the documentation?  If the
first, just ask more aggressively, if the latter, please send us
suggestions where to improve.  Sometimes we live too much in the
Scheme world, maybe, and someone needs to get us back.

Best regards,
  'martin