[Top][All Lists]

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


From: Mikael Djurfeldt
Subject: Re: SLIB
Date: Thu, 16 Aug 2007 10:24:46 +0200

2007/8/16, Kevin Ryde <address@hidden>:
> "Mikael Djurfeldt" <address@hidden> writes:
> >
> > slib.scm makes sure that each time
> > some module requires new slib code, it will be loaded into the module
> > (ice-9 slib) and exported from there.  I'm not at all sure that
> > guile.init does that,
> I suspect it doesn't.  It'd be cute if going through (ice-9 slib) worked
> with the module system so you could get slib in some modules and not
> others.

If I understand you correctly, I'd say that it currently does work
like that.  The idea is that slib lives in (ice-9 slib) and that all
public functions are exported from there to all who uses (ice-9 slib).

>  In particular it'd help for the various funcs in slib which
> clash with guile core bits, like the different flavour of `system', and
> the separate `provided?' feature list which Greg mentioned.

I haven't read what Greg has written about this, but, yes, probably
some aspects of slib needs to be updated.

>  But I think it depends what Aubrey want to do.

Yes, ideally, you should coordinate this with Aubrey.  Why not explain
the situation for him?  I think the simplest solution would be to use
the main idea of (ice-9 slib) explained above.  Maybe Aubrey could
strip down guile.init a bit so that ice-9/slib.scm could load
guil.init and add the Guile module system specific things to make
loading into (ice-9 slib) and exporting from it work?

>  For now I think guile.init is only
> really setup to be loaded into the top-level environment to transmute it
> into an slib environment.

I disagree.  Just loading guile.init in its current form simply does
not work together with the Guile module system.  Unfortunately, it
doesn't become obvious until one has used it enough.

reply via email to

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