This is the mail archive of the guile@cygnus.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] |
mdj@nada.kth.se writes: > 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. > Yes, I know. I don't think it is a very good way to test that for at least the following reasons: * It does not account for all such compile-time differences. For instance, many of the individual POSIX functions are compiled in only conditionally, but they do not each have their own *features* entry, and it would be nonsensical to do that. * Many things are listed in *features* that will _always_ be provided by Guile. * *features* does not describe the difference between different versions of Guile. * I think `defined?' is a better solution to knowing what optional procedures you have compiled in. The only problem this can't solve is detecting significant differences in behavior of the same procedure depending on compile-time conditions, but I don't believe *features* is being used for any such things right now that are not consistent across all Guile builds anyway. Thus, *features* is a useless way to try to write portable Guile code, and a better solution (`defined?') already exists. Thus, I consider it only useful for SLIB compatibility. > 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. See above. - Maciej Stachowiak