[fetter-devel] Quick CFFI update

[C Y]

--- Kenny Tilton <ktilton at nyc.rr.com> wrote:
>
> CFFI seems from a distance to be something for the open source 
> crowd. "commercial lisps" are left as an exercise. 

This isn't too surprising, is it?  Commercial lisps can be expensive if
you get a license that allows a wide variety of uses, and since CFFI is
a free tool it would make sense it doesn't have the resources to work
on the commercial lisps (at least initially.)  Also, open source can be
an area where new ideas and standards prove themselves, and gain in
popularity to the point where the commercial guys would be interested
in helping out.  I for one am very hopefull that cffi, fetter, and
Hello-C can finally bring an era of uniform foreign function
interfacing to Common Lisp, and perhaps form the core of a revision of
ANSI.

> Is this because it was  expected one would have to hack on the 
> implementations? Or this may be because of performance issues? ie, 
> CMUCL needed a fix? I do not know.

Well, minimally, wouldn't it need extensive testing on all lisps it is
intended to run on?

> Anyway, any "universal" FFI has to handle popular commercial lisps.

I'm thinking vendor support would make that MUCH easier - I doubt they
would flock to an open source project unless they are sure it is the
"winner".

> Is the idea that we do an end run on the different implementations' 
> incompatible high-level APIs by resolving differences at a
> lower-level, perhaps unsupported or even unavailable level? 

Wouldn't that make the most sense?  I.e.:

bottom layer -> implimentation specific stuff - whatever low level
stuff the lisps provide themselves
CFFI -> low level, using what the various lisps provide when it works
and implimenting what is needed when it isn't available.  CFFI should
provide an interface which is both uniform and low level.
Hello-C/UFFI/Fetter -> function as the top layer, the friendly layer
that most programmers interact with.  Not as powerful as CFFI perhaps
but hiding all the nastiness of FFI interaction that can be hidden.

The various lisps' high level APIs would then function more or less
independantly.  We "borrow" whatever features seem nice from each, but
essentially state that there is the "uniform" top level api and then
each implimentations high level API, those that have one.  For those
without, Hello-C/UFFI/Fetter becomes the ONLY high level API available.

> Whereas with CFFI at the lower level we have 
> fewer places that can diverge (and no matter what the high-level API 
> looks like, they are bound to support certain lowlevel capabilities)?

That makes sense to me - establish low level uniformity with CFFI, and
build a new, standard layer or layers on top of it.  This hides
individual lisp weirdness from the user.

The way this exercise makes the most sense to me is if it tries to do
things the Right Way and becomes the Final solution for Lisp FFI
interfacing.  This is one of (perhaps the biggest, after lack of a
portable, native, friendly graphics layer) problems lisp as a language
faces.  Yet Another FFI probably won't help much, but a final, uniform
solution everyone can agree is the best way to go would help
tremendously.

Of course, that's just me.

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com