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]

Re: *features*


Maciej Stachowiak <mstachow@MIT.EDU> writes:

> > 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.

Do we need a single mechanism which accounts for all compile-time
differences?  I agree that `defined?' seems to be the best choice to
check for primitive procedures, unless you need the information before
loading the library.

> * Many things are listed in *features* that will _always_ be provided
> by Guile.

You can also imagine that some people would like to build a special
variant of Guile for some dedicated purpose, like a small Guile in an
embedded controller which doesn't use bignums.

> * *features* does not describe the difference between different
> versions of Guile.

No, *features* describes what is available in the Guile which you
run.  I'm not sure what you are referring to?

> * 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.

But that is not a problem of the mechanism, rather of how it's used.

> 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'm no special fan of *features* but I'd like to know that we only
remove it if it really is useless, or, if it isn't completely useless
but rather just bad, that we add some other mechanism which is better.

I can see the following categories which are trickier to solve with
`defined?':

* features which are properties of the system rather than optional
  procedures (e.g. which parts of the numerical tower are present).
  (Yes, I know that I may be able to device tests for some cases, but
   it would be nice to have a simpler mechanism.)

* (as you pointed out) differences in behaviour of procedures

* cases where you'd not like to load the module to be able to do the
  `defined?' test.  (It is not obvious how this should be handled but
  the module system needs to be involved.)

/mdj