From: "Mikael Djurfeldt" <mikael@djurfeldt.com>
To: "Greg Troxel" <gdt@ir.bbn.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: Heads up: Releasing 1.8.2
Date: Tue, 26 Jun 2007 17:34:39 +0200 [thread overview]
Message-ID: <66e540fe0706260834s4d820fcdq8ad1e11c5bcd1e15@mail.gmail.com> (raw)
In-Reply-To: <rmibqf2gb7b.fsf@fnord.ir.bbn.com>
2007/6/26, Greg Troxel <gdt@ir.bbn.com>:
> 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.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2007-06-26 15:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-23 15:43 Heads up: Releasing 1.8.2 Ludovic Courtès
2007-06-24 22:31 ` Greg Troxel
2007-06-25 8:11 ` Ludovic Courtès
2007-06-25 12:42 ` Mikael Djurfeldt
2007-06-26 12:19 ` Greg Troxel
2007-06-26 15:34 ` Mikael Djurfeldt [this message]
2007-08-15 23:08 ` Kevin Ryde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=66e540fe0706260834s4d820fcdq8ad1e11c5bcd1e15@mail.gmail.com \
--to=mikael@djurfeldt.com \
--cc=gdt@ir.bbn.com \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).