This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Will guile ever have (or care about having) users?



After following this list for many years, and trying to use guile for
extension I have come to the conclusion that the guile community, as
represented by this list, does care about having, and in fact does not
want actual users of guile.  Since guile is being developed by
volunteers it is fine for everyone to do whatever they wish.  However,
it seems a bit disingenuous to have an "official" guile web page which
touts the benefits of guile as an extension language when every effort
appears to be made by the community to hinder such use.
Documentation? Examples? Useful discussions of user issues?  Perhaps
it's just that I don't have the right time perspective.  I've only
been interested in and followed guile (at various levels) for 12 or so
years.  Since the One True Module system or the One True GC takes true
inspiration and a lot of work, we can expect that it will take years
longer than something more pedestrian, like say the Late Quartets.

In response to a message I posted the other day regarding difficulties
I was having with the gh_* interface and the module system I received
one reply.  The gist of this message is:

>>> However, unless I'm wrong, all of this is in the (guile) module, while
>>> I am in the (guile-user) module once I enter the repl. 

>I'm using my own version of guile and use the environment API to
>manipulate module bindings, but as far as I can tell the gh_*
>functions should always operate in(guile_user) and not in (guile).

I followed this with a longer reply, both to the author and the list,
with sample code and output.  These facts demonstrated that at least
to the extent I understood the interactions, and certainly in the
operational manifestation of these interactions, my original assertion
was correct.  Neither the author or anyone on the list ever
responded.  The predominant topic of the list following this, with
spirited interaction, once again returned to the GC.

The problem I am trying to solve, I thought, follows pretty exactly
the primary stated goals of the guile project in guile providing an
extension language for other code.  My problem is using numerical code
in C to solve some chemical physics problems.  I followed the only
instructions I can find in an older document "guile-ref.info".  (All
GNU software is supposed to, I thought, come with info pages.  For
most of my 15+ year of using it this has been the standard).  I have
embedded scm in many programs and the gh_ interface is easier.

The problems I face stem from what I understand to be the fact that
before entering the repl the gh_ functions operate in (guile) and
after they operate in (guile-user).  This is not such a problem at
first, since functions defined in (guile) will be found via the
hierarchical search from (guile-user).

However, gh_lookup() operates in (guile).  To lookup something in
(guile-user) you have to use gh_module_lookup() which requires the
module vector.  (I assume this is the obarray but I could be wrong).
I don't think this even exists before you have entered the repl and
created the (guile-user) module, but I can't find this documented.
Nowhere have I found documented (or in the code) examples of how one
writes code so that gh_lookup(), or actually gh_module_lookup() does
it's lookup in (guile-user), all from C functions and not requiring
any scheme code to be run after entering the repl.

Unless I'm mistaken, a system in which some primitives are written in
C (or bytecode) and which can be redifined by the user via a natural
and standard mechanism, is intrinsic to most Lisp/Scheme
implementations.  Emacs provides a common reference.

In the current guile (1.4) a scheme function written in C, called from
another C function via gh_lookup() will not be replaced by a user
redefinition from the repl (guile-user), yet a direct call to this
function will be redefined.

This behavior makes the use of guile as an extension language nearly
impossible.  Think of trying to understand emacs if you had to know if
how and where every function was called to understand how redefining
it would effect your editor.

Perhaps I just missed the correct function in the documentation and
there is a gh_ call that lets a C function call scheme or SCM functions
in exactly the same manner as the repl so that the behavior is as
expected.  

Or perhaps we really aren't meant to just bolt guile onto our
application as an extension language.

-John

John Daschbach
Senior Research Scientist
Pacific Northwest National Lab
Richland WA
jl_daschbach@pnl.gov







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]