guile-devel
[Top][All Lists]
Advanced

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

Re: Heads up: Releasing 1.8.2


From: Mikael Djurfeldt
Subject: Re: Heads up: Releasing 1.8.2
Date: Tue, 26 Jun 2007 17:34:39 +0200

2007/6/26, Greg Troxel <address@hidden>:
I should note that the 1.8.1 I'm using replaces ice-9/slib.scm:
[...]
        echo "(define-module (ice-9 slib))" > ${WRKSRC}/ice-9/slib.scm
        echo "(load-from-path \"slib/guile.init\")" >> ${WRKSRC}/ice-9/slib.scm
>  Preferably, the Guile part of
> slib should be minimal, giving larger freedom for development on both
> sides.

I agree.  The above is pretty minimal, except that there's a definition
of provide and require.

It's not minimal at all.  guile.init contains over 600 lines of code,
many of which refers to peculiarities and internals of specific
versions of Guile.  A lot of that code belongs more naturally to the
Guile side of the interface to slib.  What you should try to achieve
is a minimal *interface* towards slib which is not likely to change.
The Guile side of this interface can then be voluminous as long as
that code is maintained by the Guile developers.

Things like (guile.init):
;;; Hack to make syncase macros work in the slib module
(if (nested-ref the-root-module '(app modules ice-9 syncase))
   (set-object-property! (module-local-variable (current-module) 'define)
                          '*sc-expander*
                          '(define)))

should not be used in an interface to all versions of Guile and should
not be maintained by Aubrey Jaffer.

Probably slib should have a procedure that's callable just after init to
give it a list of names that the native implementation provides.  I see
no need for provide native guile to have provide/require.

Right.  In any case, the list of features should not, as it is now, be
provided in slib's guile.init, because it is bound to be false for
some Guile versions.

I think that fixing the requires confusion and slib/module system
interaction are orthogonal, and that we might as well do the requires
stuff first.

Sounds reasonable.




reply via email to

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