On 22-Jun-2004, Malcolm Wallace wrote:

Fergus Henderson writes:

...

| Hat/Foo/List.hs:1: | Ambiguous occurrence `List' | It could refer to either `Hat.Hat.List', imported from Hat.Prelude at | Hat/Foo/List.hs:30 | or `Hat.Foo.List.List', defined at | Hat/Foo/List.hs:32

Unfortunately, ghc-6 seems to be rather over-eager to report ambiguous use of identifiers, where in fact the usage is not ambiguous (the Hat.Hat versions are only visible qualified, whereas your Foo.List is visible unqualified).

The Hat.Hat versions are imported unqualified in line 30 of Hat/Foo/List.hs, which is "import Hat.Prelude". So I think this is a Hat bug, not a ghc bug.

Ideally we will try to find a fix for this. In the meantime, you can work around the bug either by renaming your own versions of the overlapping identifiers, or always using them qualified (including in export lists).

And including in _implicit_ export lists? Well, I tried that, but the result was another Hat bug: a pattern match failure for the following function in src/hattrans/TraceId.hs: tyClsInfo :: TraceId -> TyCls tyClsInfo (TI _ (Just (TyCls tyCls))) = tyCls | bash$ hmake -hat Main.hs | hat-trans Foo/List.hs | Creating directories Hat Hat/Foo | | Fail: TraceId.hs:152: Non-exhaustive patterns in function tyClsInfo | | bash$ cat Main.hs | import Foo.List | main = Foo.List.main | | bash$ cat Foo/List.hs | module Foo.List(Foo.List,main) where | | class List a b where | foo :: a -> b | | main :: IO () | main = return () -- Fergus J. Henderson | "I have always known that the pursuit Galois Connections, Inc. | of excellence is a lethal habit" Phone: +1 503 626 6616 | -- the last words of T. S. Garp.

...

Fail: TraceId.hs:152: Non-exhaustive patterns in function tyClsInfo

I couldn't reproduce this bug with the current CVS sources.

Further to this, I have found some existing patches to Hat-2.02 that enable qualified use of class names, so perhaps these are missing from your version. Regards, Malcolm

Fergus Henderson 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/

On 23-Jun-2004, Malcolm Wallace wrote:

...

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.

I have just checked into CVS a tracing version of Data.Word.

Thanks!

It compiles, but I haven't tested it. Currently it provides instances of Eq, Ord, Bounded, Num, Enum, Read, Show but omits instances of Real, Integral, Ix because of tedious errors I haven't tracked down. If you need those instances, I'll look into it further.

It turns out that I do need at least the Integral instances. I tried uncommenting those, and got an error about "fromRational" being undeclared. I then tried adding "import Prelude(fromRational)" to src/hatlib/Data/Word.hs, but that didn't work. I ran into the following problem: | bash$ make | cd src/hatlib; make HC=ghc6 all | make[1]: Entering directory `/home/fjh007/hat/cvs/hat/src/hatlib' | /home/fjh007/hat/cvs/hat/script/hat-trans -P. -I. -trusted -prelude -D__GLASGOW_HASKELL__=620 Data/Word.hs | | Fail: AuxLabelAST.letVar: == not let-bound in env The build continued a little longer, | ghc6 -package-name hat -fglasgow-exts -package lang -package base -fno-warn-overlapping-patterns -fno-warn-missing-methods -i/home/fjh007/hat/cvs/hat/targets/ix86-Linux/obj/hatlib/ghc6 -I. -I/home/fjh007/hat/cvs/hat/include '-#include "hat-c.h"' -c -o /home/fjh007/hat/cvs/hat/targets/ix86-Linux/obj/hatlib/ghc6/Hat/Data/Word.o Hat/Data/Word.hs | | Hat/Data/Word.hs:1: | The main function `main' is not defined in module `Main' | make[1]: *** [/home/fjh007/hat/cvs/hat/targets/ix86-Linux/obj/hatlib/ghc6/Hat/Data/Word.o] Error 1 but I think the first error message is the one that is really causing the problem. Cheers, Fergus. -- Fergus J. Henderson | "I have always known that the pursuit Galois Connections, Inc. | of excellence is a lethal habit" Phone: +1 503 626 6616 | -- the last words of T. S. Garp.

I wrote:

The following wrapper: foreign import haskell "Prelude.toRational" toRatWord8 :: Word8 -> Rational is the culprit.

I've now found a reasonable workaround and checked it into CVS. Happily, there is no need to attempt to construct a traced Rational primitively - we can do it in plain Haskell code instead: instance Real Word8 where { toRational x = toInteger x % 1 } Regards, Malcolm

Fergus Henderson writes:

This one can be reproduced with a simple one-liner, "(>>) = 42":

bash$ cat Foo.hs (>>) = 42

Hmm, but isn't (>>) indeed defined in the Prelude? So what is the expectation here? Is it something to do with lazy reporting of name clashes?

bash$ cat Foo.hs import Prelude hiding (Prelude.head)

fjh$ hmake -hat Foo hat-trans Foo.hs

Fail: Variable or constructor not in scope: Prelude.head

Probably easy to fix. I'll look into it tomorrow. Regards, Malcolm

Fergus Henderson writes:

...

...

(>>) = 42

The name ">>" is defined in the Prelude, but this occurrence of ">>" in Foo.hs is a definition, so it unambiguously refers to Main.>>, not Prelude.>>.

Yes, OK, accepted. The problem here is that the Hat transformation introduces three replacement definitions for the original function: a worker, a wrapper, and an atom. The worker is used on the RHS of the wrapper definition, and the atom is used on the RHS of the worker definition. These RHS usages should be qualified for disambiguation. Thus, hat-trans ought to check whether a top-level variable is already in scope at its point of definition, and if so, qualify those newly introduced uses. Unfortunately, it looks like a considerable amount of internal plumbing will need to be added to hat-trans to enable this check. In the meantime, a plausible workaround would be: import Prelude hiding ((>>)) import qualified Prelude (>>) = 42 but at the moment, this does not work either, because the transformed version only hides the imported wrapper function (!>>) but not the worker (|>>) or atom (+>>). I have attached a possible fix, but with it, the Hat prelude can no longer be transformed correctly, so you should not try to rebuild that. Olaf might like to comment on or refine the patch. Regards, Malcolm

I wrote:

I have attached a possible fix, but with it, the Hat prelude can no longer be transformed correctly, so you should not try to rebuild that.

Actually, the non-rebuildability of the Hat prelude turned out to be another bug, only made visible by the fix I suggested. Here is a patch to the Prelude which corrects that secondary fault. Since the combination of the two patches now seems to work, I'm committing them to CVS. Regards, Malcolm