[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guile Impressions

From: John Fitzgerald
Subject: Guile Impressions
Date: Tue, 8 May 2001 10:13:54 +1200

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'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.

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).  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.

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.  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.

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.

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.)

Okay, so these are the major issues as I see them, but I'm only one person
and I am as I said at the periphery.  Obviously others will have different
wants and desires for Guile, and much if not all of the work is being done
by a small number in their own limited time who have a right to pursue the
areas they feel most impassioned about.  But let's open it up for

NOTICE: The information contained in this electronic mail message and any
attachments is confidential to Pavilion Technologies, Inc. or one of its
subsidiaries and may contain proprietary information or be legally
privileged. This message and any attachments are intended only for the
personal and confidential use of the designated recipient(s). If you are not
the intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have recieved this
message in error, and that any review, dissemination, distribution or
copying of this message and any attachments is unauthorized and strictly
prohibited. If you have received this message in error, please notify me
immediately by telephone and electronic mail, and delete this message, any
attachments, and all copies thereof. Thank you very much  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]