FFI Report comments

[Manuel M. T. Chakravarty]

[I'll just respond to a couple of points, the rest I have
silently accepted or put on the todo list, or it will be
discussed in a later message.  This includes Malcolm's first
email, too.]

Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> wrote,

> Lexical Structure
> ~~~~~~~~~~~~~~~~~
> The lexical syntax adds 'foreign' as a keyword (reservedid).  I'm not
> entirely convinced this is necessary.  Certainly in nhc98 we treat
> 'foreign' as just a specialid, and so like with other specialids you
> can name a variable 'foreign' if you wish.  In other words, is there
> any real reason to exclude the possibility of
> 
>     module F (foreign, as) where
> 
>     foreign :: X -> Y
>     foreign ... = ...
> 
>     foreign import ccall "something" as :: CInt -> CInt -> CInt
> 
> which nhc98 currently accepts, but ghc -fglasgow-exts rejects?

As I understand H98's distinction between reservedids and
specialids, any id that introduces a new grammatical phrase
is a reservedid.  Otherwise, why is `data' not a specialid?

So, I believe it is more inline with H98 to make `foreign' a
reservedid.

> Standard C Calls
> ~~~~~~~~~~~~~~~~
> The productions
> 
>     fdecl  -> 'import' callconv [safety] entity var '::' ftype
>     entity -> " ['static'] [fname] ['&'] ['['lib']'] [cid] "
> 
> suggest that the entity string must always be present, but could be
> "".  I was wondering if there is any real difficulty in permitting
> an empty entity string to be omitted altogether?  The idea would be
> to be able to write
> 
>     foreign import ccall sin :: CFloat -> CFloat
> 
> as at present rather than
> 
>     foreign import ccall "" sin :: CFloat -> CFloat
> 
> It isn't a big deal, and it might be worth enforcing the literal string
> quotes just for uniformity, but I thought I'd raise the issue anyway.

Then, we also have to define

  entity -> [string]

at the start of Section 3.  I actually considered this, but
just went for the simpler syntax.  But I would also be happy
to allow omitting the "".

> Int and Word
> ~~~~~~~~~~~~
> You want to drop the assertion that "arithmetic is performed
> modulo 2^n" for sized Int and Word types, on the grounds that this
> doesn't hold for Int.  But Int is not of fixed size, so how could it
> require modulo arithmetic!  I happen to think the fact that Int is of
> unspecified size >30 bits, with undefined behaviour on overflow, was
> something of a mistake in Haskell.  Now that we have the opportunity
> to define a sensible overflow behaviour for fixed size types, I think
> we should take it.

Ok - the general opinion here seems clear.

> module StablePtr
> ~~~~~~~~~~~~~~~~
> It seems a little strange that there is an instance of Storable
> for StablePtr, yet we are forbidden to use the methods of Storable
> to dereference a StablePtr.  In other words, I'm not quite clear on
> exactly what is being forbidden.

The Storable instance allows to store `StablePtr's
themselves (ie, the value that represents them) rather than
then the value that they refer to - the latter may not be
accesses using Storable.

Cheers,
Manuel