On Tue, Apr 8, 2008 at 6:30 AM, dherring@tentpost.com wrote:
Until we get a CDR/other generally accepted spec on how *features* should reflect the platform, there are no wrong settings in *features*. Since this is a global value, special care must be taken to not break code which has already been tuned for an implementation. It seems rude for a nested library to change common global settings.
Again, I agree with you that it doesn't feel very good at first sight. But, can you give me an example how trivial-features would break existing code? AFAICT, implementations seem to introduce aliases for already existing keywords in *features* from time to time. That is what trivial-features does as well.
Putting a prefix on all customized features
- minimizes conflicts with implementation-specific flags
Can you give me an example?
- is explicit about intent; #+:unix says "I want unix".
#+:tf-unix says "I want a tf-compliant unix".
OTOH, as implementations start to agree with each other, one can simply drop the trivial-features dependency and not have to change any code.
Also, implementations already agree on 80%[1] of this stuff. So you can write #+unix and pull in trivial-features and make it work on that one Lisp that doesn't push :UNIX to features (ECL on Darwin) instead of having to write (or, most likely, forgetting to write) #+(and unix darwin) or #+(or unix (and ecl darwin)).
My rationale is that the above pragmatic advantages outweight the low probability of incompatibilities due to the rudeness of making global changes to *features*. I may be wrong, of course.
This branch adds three new dependencies. Babel for string translation is understandable. Alexandria and trivial-features are somewhat less obvious.
The new string code could be moved into a separate ASDF system with a different type and have only that depend on Babel. The Alexandria utilities being used could be copied and pasted into CFFI and Babel. The endianess feature detection code could be copied and pasted into Babel as well. And the cffi-features stuff can stay as it is, instead of being replaced by trivial-features. I'm not (yet?) convinced it's worth the trouble.
If the core cffi is introducing these dependencies, then I'm checking that we gain something tangible in return.
At first they were introduced by Babel (which can't use cffi-features unless we move CFFI's external-format code onto a different system), then it's just seemed natural to use them in CFFI as well.
[1] made-up figure.