[cffi-devel] Merging the cffi+lotsastuff branch; new dependencies

[Daniel Herring]

On Tue, 8 Apr 2008, Lu?s Oliveira wrote:
> On Tue, Apr 8, 2008 at 6:30 AM,  <dherring at 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