Manuel M T Chakravarty
* 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