*features*

[Mikael Djurfeldt <mdj@nada.kth.se>]

Maciej Stachowiak <mstachow@MIT.EDU> writes:

> > (The file sort.c will provide the same interface as slib so that we
> >  can add 'sort to *features*.)
> 
> Hmm, this reminds me of something that has been bugging me. A lot of
> code both in libguile and boot-9.scm munges *features*. I am of the
> opinion that the only manipulation of *features* should happen in
> slib.scm, because slib is the only thing it is really useful
> for. Again IMO, user code for Guile should not be encouraged to
> examine *features*.

It seems as if you regard *features* only as something added for
compatibility with slib.

It's not intended to be only that.  It's rather a mechanism of its
own.  We use it to determine what features have been added in the
system.  For example, it is used to check what pieces of code has been
conditionally compiled into libguile.

The piece of code C may be dependant upon OS function call P.  Let's
say that architecture A supplies P, but architecture B doesn't.

On A, C is included in the library.  C contains a call to
scm_add_feature which adds the feature to *features*.  On B, C isn't
included.

I think it is good to have such a mechanism, and, given slib's
*features*, I don't see any strong reason for implementing it
differently.

And since it is a Guile mechanism it isn't wrong for GUile code to use
it.

/mdj