[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@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