FFI Report comments
Manuel M. T. Chakravarty
chak at cse.unsw.edu.au
Thu Aug 30 10:57:49 EDT 2001
[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
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
> 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.
More information about the FFI