[Hat] Hat bug report: Ambiguous occurrence `List'

[Malcolm Wallace]

Fergus Henderson <fjh007 at galois.com> writes:

> The main problem here
> seems to be that Hat doesn't support the "Data.Word" module.  Is there any
> simple work-around?  I'm not particularly interested in tracing that module.

The range of hierarchical libraries supported by Hat is still rather
limited at the moment I'm afraid.  There is a full list of supported
and unsupported modules from -package base in docs/libraries.html.
Apart from Data.Word, I notice your command-line also mentions the
concurrent, net, and posix packages, none of which are yet supported
either.

In principle, it shouldn't be too difficult to plug some of these
things in.  There are two issues:

  * Translate the library sources with hat-trans.  Provided you want to
    'trust' the library module, and it deals only in standard
    datatypes, this is just a question of copying the sources into
    the hatlib build tree and updating the Makefile.

  * Dealing with primitive types, e.g. Int8, Word16, Socket, etc.
    Each primitive type needs a wrapper type and a couple of wrapper
    functions to be written by hand, to<Type> and from<Type>.  You will
    see examples of these in, for instance, Hat/PreludeBuiltinTypes.hs
    and Hat/Foreign/BuiltinTypes.hs.

    All primitive functions that manipulate primitive types then also
    need to be wrapped by hand.  The mechanism is illustrated by this:

        import qualified TraceOrigChar
        foreign import haskell "Char.isAscii" isAscii :: Char -> Bool

        import qualified TraceOrigForeign.ForeignPtr
        foreign import haskell "Prelude.=="
            eqForeignPtr :: ForeignPtr a -> ForeignPtr a -> Bool

    and you can see numerous more examples in PreludeBuiltin.hs,
    Directory.hs, IO.hs, Foreign/ForeignPtr.hs and so on

I'm sure a lot of this boilerplate could be automated, given a fairly
simple specification of the complete module signature, and it is on
our to-do list for when we manage to persuade a funding agency to
support the next stage of research on Hat.  But in the meantime, it
is just another tedious job to be done by hand.

A word of warning about concurrency.  We don't yet know in detail
what it would mean to trace a concurrent program.  There are probably
locking issues when writing to the (shared) trace file.  There may
be graph-connectedness issues for the separate threads.  And we have
no support for examining faults related to concurrency itself, such as
the successive values acquired by an MVar.  (But see [1].)

> I'm not quite sure why it goes on and invokes /usr/bin/haskell-compiler
> after the openFile failure.  But that's a side issue.

Yes, this is a bug in hmake.

Regards,
    Malcolm

[1] Concurrent Haskell Debugger, Frank Huch,
    http://www.informatik.uni-kiel.de/~fhu/chd/