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

[Luís Oliveira]

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?


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

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/