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]

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


On Wed, Jul 19, 2000 at 12:49:15PM -0400, John Daschbach wrote:
> 
> 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.

A bit harsh but not too far off the mark.

I have been using scm_symbol_value0() to fetch the value of symbols
from within my extension programs. It isn't documented, it probably
never will be, but it does what I was expecting gh_lookup() to do.

On the other hand gh_define() does exactly what I would expect it
to do. This issue has come up on the list before, I remember answering
it before and it is all about module namespaces, something which has
been up in the air for way too long.

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

Yup, my program boots guile (through stolen main() as per requirement)
then adds all the extension functions and SMOBs into the system,
then jumps into the normal REPL to provide a prompt to the user.
Thus it behaves like an extended guile (i.e. the normal guile prompt
is the front end and my code is the back end) rather than as an
application which uses guile as an extension language. In my opinion
(and this is based on trying these things) guile is easiest to use
in the way I am using it.

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

Yeah, same, thats why I dropped back to the scm_symbol_value0()
function (which, by the way, takes a single C-style string as
its argument).

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

I think this is right but it depends on how the first scheme function
written in C got linked into the namespace. I agree that namespace
management is counterintuitive but my approach has always been to just
try things until something works and then keep going (and not be afraid
to pull random chunks of guile source apart to figure out how it works).

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

Emacs believes in the ``one massive namespace'' approach which does have
a few points in its favour -- it is easy to understand, easy to explain
to someone who doesn't understand, and easy to implement. However,
as emacs has discovered, there is a point where management of a single
massive namespace becomes rather difficult.

Scheme (in its purest sense) believes in the ``one massive namespace,
oh yeah and closures, but they aren't really intended for what you are
about to use them for, oops, oh well, I guess it seems to be working''
philosophy which is at least a slight step up on LISP in terms of
keeping control over complex systems.

Sadly, the ideal approach is yet to be found, and the intermediate
steps in getting there can be worse than what we started off with.

By the way, closures can be used to implement highly complex
namespace management and also object oriented systems but most
of the scheme community seems to feel that this is not the way
to go, so we are going towards environments and modules and such
instead. For example, it would not be terribly difficult to
make a macro called ``closure'' which worked like:

(closure bill
	(define fred 1)
	(define (sally x) (+ x fred)))

(bill 'fred)  => 1
((bill 'sally) 5)  => 6

Then we can have a whole heap of namespace neatly wrapped inside
a single object. It can also be extracted as required:

(define fred (bill 'fred))
(define sally (bill 'sally))

And would require some internal magic to provide mass-extraction
of namespace terms from the closure if that was really what the
users required.

Well anyway, there are heaps of ways to do it, figuring out which
one is really better will probably take longer than my lifetime.
Anything simple that works is good from my point of view.

	- Tel

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