On Tue, 8 Apr 2008, Lu?s Oliveira wrote:
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?
Unfortunately nothing new. The SBCL :unix on windows is the worst I knew of. It might just be my overactive imagination.
The moral equivalent to *features* in C/C++ are #define macros. There, programmers learned through pain that every library should prefix its macros with a library-specific prefix; the common names are always taken for differen purposes by several libs, leading to bizarre errors depending on header #include order. For example, the Boost libraries define things like BOOST_NO_AUTO_PTR and BOOST_NO_EXCEPTIONS when they detect implementation abnormalities.
In lisp, it would be important that trivial-features always loads before any other library which uses *features*; or else those loading prior might get incompatible settings with those loading after.
Since *features* is generally less-heavily used than #defines, its less of a problem, but I'm still uneasy about this. I guess it just depends on the scope of what you're trying to achieve.
- 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.
Devil's advocate then says, "CFFI doesn't require trivial-features; but if it starts acting funny, you might try loading tf and then recompiling cffi."
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.
Ahh. Thanks for the explanation. Babel sounds like a generally good thing, so the others are good by association.
Following the principle of put up or shut up, I withdraw my objection to merging this branch.
Later, Daniel