ANN: H98 FFI Addendum 1.0, Release Candidate 10

[Malcolm Wallace]

> > Let's be clear about the role of Point here:  it is a dummy type
> > argument to Ptr, used to disambiguate the type 'Ptr Point' from any
> > other kind of Ptr.  It is for type-safety in the Haskell code.
> > 
> > It doesn't matter how many values of the type Point there are.  I could
> > use any Haskell type with the same results.
> >
> > There definitely aren't any values of type Point, so I don't see why it
> > needs a semantics.

OK, I think I agree with all of this.

> My main problem with this extension is the following:
> 
> * As we have learnt, nhc98 and Hugs use `data T' for an
>   entirely different purpose than the one proposed by John
>   (namely to represent primitive external types).  It may be
>   possible to abuse nhc98 and Hugs `data T' also in the way
>   John wants it (and GHC provides it), but this sounds less
>   straight forward than initially where the impression was
>   given that the three systems already implement the same
>   extension.

Actually, I think both Hugs and nhc98 straightforwardly allow
John's use.  All three systems do implement the same extension.

In fact it is the current usage of 'data T' for primitive types that
is tricky.  At the moment, basically they must be *internal* types,
i.e. types already known to the Haskell runtime system.  The idea
of using them for external, previously unknown, types is entirely
speculative.  It would require somehow specifying storage sizes, and
routines to marshal values into the heap, and perhaps more.  None of
these mechanisms yet exist.  The question was raised as to whether we
might one day want those facilities, because the natural place to
specify them is in the FFI.  But no-one even has a proposal for how
it might work, so I think we can safely dismiss it at this stage.

> > >   data Point
> > >   foreign import getMousePos :: Ptr Point ->  IO ()
> > >   foreign import getX :: Ptr Point -> IO Int
> > >   foreign import getY :: Ptr Point -> IO Int

vs

>   data Point = Point (Ptr Point)
>   foreign import getMousePos :: Point ->  IO ()

I like the second idiom.  You are right that there is no need for
the application programmer to know whether pointers are involved,
because even in the first style, it is not possible to 'peek' inside
a Ptr Point to get the `actual' Point value.  So why not hide the
pointer altogether?  Yes.

Regards,
    Malcolm