Typing f.e.d.

[Alastair Reid]

> Alastair Reid wrote:
> > [...] ps I have a feeling of feeping creaturism as I watch this list -
> > a nice simple design seems to be getting more complex.
>
> Could you elaborate on this? The basic FFI *is* still nice and simple
> IMHO.

I'm thinking of:

1) Trying to support a complex language like Java in the same design (or in any
design, really)

   My sense is that this will gradually infect the ffi design with the
complexities of the other language and that this effect will be worsened by the
mismatch between the two type systems.

2) Moving library specs, etc. out of the individual ffi decls.

  This seems to be partly motivated by supporting Java and partly by
convenience and a dislike of cpp.

> Mentioning plain Addr in it was a design mistake because:
>
>    * Pointers to code and data need not have the same size.

I understand this argument though I'm not sure which architectures this applies
to.
Alphas?

>    * The extra type parameter in Ptr/FunPtr tremendously helps to resolve
>      overloading ambiguities.
>    * Addr doesn't carry any type information, so there is no help at all
>      from the type checker, which is even worse than C.

I remember briefly using the same trick in the early greencard days but gave up
on it because I found myself wanting a many-to-many relationship between C
types and Haskell types and using overloading and an extra type parameter I
could only get a one-to-many relationship.  (This is what greencard's DIS's
give you.)  So I've been sitting here wondering how things are turning out in
practice.  For example:

How often do you have to create two Haskell types which really ought to be just
one type just so that you can use the overloading?

Is pointer arithmetic on Ptr's useful?  (It's obviously useful for arrays but
can you use it (safely and portably) to access fields of structs or do you have
to add an explicit byte count to get predictable/safe results.)

What's the preferred way to represent an opaque C data type which happens to be
a pointer?
With Addr, I'd use:

  newtype AbstractFoo = MkAbstractFoo Addr

Should I use Ptr () instead?

What libraries is the evolving design being tried out on (I know about your
OpenGL library).

> Admittedly, we have to be a little bit careful with the FFI libs

I'm less concerned about the ffi libs because:

1) As a user, I only _have_ to use the low level ffi libraries: Addr, Word,
   Int64, ForeignObj, etc.   Its nice if the high level libraries are useful
   too but not essential.

2) As an ffi implementer/maintainer, I only have to implement the agreed
   ffi interface and all the libraries on top will "just work".

3) They're not supposed to be standard so it's ok to experiment with the
   design a bit.

4) I don't have any code that uses them.


--
Alastair Reid

ps I tried to find a copy of the ffi spec on haskell.org today.
   After some searching, the only version I could find was more than a year
old.
   I have a note somewhere of where the up-to-date copy is held but if anyone
   were to go looking for it themselves, they might have a hard time.

   It'd be good to sprinkle haskell.org with a few pointers to the current spec
   before Wednesday (which is when Hugs 2001 (including my ffi implementation)
   will be released.