[nhc-bugs] nhc98 1.14 FFI issues

[Malcolm Wallace]

Manuel M T Chakravarty <chak@cse.unsw.edu.au> writes:

> * nhc98 exports its FFI libraries from a module called `FFI',
>   whereas all other systems (and the standard) use `Foreign'
>   for the language-independent and `CForeign' for the
>   C-dependent libraries.

I have recently started to update nhc98's implementation of the FFI
to match the current standard, as a precursor to adopting the new
hierarchical libraries packages.  I was planning to rename nhc98's
internal FFI library modules to the new hierarchical variants, rather
than the flat namespace.  Maybe we can still do that, but access the
flat namespace through -package haskell98.

> * The FFI includes a `Bits' modules that differs from
>   nhc98's `Bit' module (different function names).

Again, module Bit belongs to an older standard - Haskell 1.3.
It should be easy enough to add Data.Bits along with the other
hierarchical libs.

> * There seems to be a problem with re-exporting identifiers,
>   which have been imported qualified.  I vaguely remember
>   that Malcolm once told me that nhc98 has a problem with
>   that.  

Yes, there are still occasional problems with re-exporting a
qualified identifier, and I have not recently had the time to track
down the cause.  Since you have a workaround, it will probably stay
on the to-do list for now.

> * I get a set of strange error messages:
> 
>   ======	Errors after type inference/checking:
>   No default for  Parsers.Token at 282:3.(1378,[(173,1432)])
>   No default for  Parsers.Token at 254:32.(1267,[(173,1433)])
>   No default for  Parsers.Token at 223:1.(1061,[(173,1188)])
>   No default for  Parsers.Token at 204:25.(1180,[(173,1187)])

nhc98 has a, how shall we put it, "curious" interpretation of Haskell's
class defaulting rules.  Whilst several people believe it to be a more
sensible design than the current defaulting rules (which include the
DMR), it does throw up occasional surprises for the uninitiated.

Essentially, nhc98 thinks there is an ambiguous type variable somewhere
in the usage of the functions it reports.  In other compilers, the
monomorphic restriction probably cuts in to solve the ambiguity,
but nhc98 does not implement the DMR.  However, nhc98 does accept an
explicit default for any class, not just the numeric classes.  Hence,
you can resolve the ambiguity with something like

    default (Integer,Double,MyType)

where MyType is an instance of the class Parsers.Token.

Regards,
    Malcolm