ANN: H98 FFI Addendum 1.0, Release Candidate 10

[Malcolm Wallace]

John Meacham wrote:

> > This was discussed here before and there seemed to be some support for
> > it, but how about adding the empty data declaration extension to the FFI
> > spec?

I agree, it would be a suitable addition to the FFI, since it is the
place where such types make most sense.


Alastair Reid <alastair at reid-consulting-uk.ltd.uk> writes:

> The correct semantics has to be something roughly like:
> 
> [[
>   The declaration
> 
>     data T
> 
>   declares a type T whose set of values are defined externally to the
>   language. [optional sentence: There are no legal Haskell operations 
>   on values of type T.]
> ]]

I don't really like the optional sentence, since it suggests that
a foreign imported function that operates over such values is not
legal Haskell.  How about something like:

  The declaration
      data T
  declares an abstract datatype T, whose values and operations are
  defined external to the Haskell language.  Values of T follow
  the semantics of the foreign language, in particular, with respect
  to mutability and the admission of the undefined value.

This raises the question of whether it should be possible to declare
foreign functions directly over such types, rather than through
pointers, e.g.

    data T
    foreign import mkT  :: IO T
    foreign import fooT :: T -> T

rather than

    data T
    foreign import mkT  :: IO (Ptr T)
    foreign import fooT :: Ptr T -> Ptr T

Obviously the former is much less safe than the latter.  However,
I know that nhc98 internally at least uses the former style in order
to implement built-in types like arrays, big integers, etc.  I'm not
suggesting we should necessarily formalise that hack as part of the
FFI standard - I'm just raising the question for consideration (and
probable rejection), so that our choice is an informed one.

> I'm not especially keen to change the syntax (especially since the existing 
> syntax is so trivial to implement) but if we're going to add this to the
> language, we should make sure the syntax and semantics are tolerably
> clear and in agreement with each other.

I'm not keen to change the syntax either.  The current style is pretty
clear to my mind.  But it is right that we should think about it.

Regards,
    Malcolm