- Hat - Haskell.org

Hat bug report: hat-stack fails on simple example
by Fergus Henderson 01 Jul '04

01 Jul '04

Attached is a very simple example program: main calls f, which calls g, which calls h, which calls error. I tried building this with hat ("hmake -hat Foo"), running it ("./Foo") and then using hat-stack ("hat-stack Foo"). But hat-stack reported no useful information. The only output was as follows: | Program terminated with error: | {in h} | Virtual stack trace: source file/line/col | _|_ no source reference | _|_ no source reference ... the same line above, repeated another 62 times ... | _|_ no source reference | _|_ no source reference I also tried using hat-trail, but I couldn't get any useful information out of that either. I am using the latest CVS version of hat with ghc 6.2. Also, hat-trail failed to properly restore the tty state after ":q". -- 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.

2 5

Hat bug report: import Prelude hiding ...
by Fergus Henderson 30 Jun '04

30 Jun '04

Although Hat does support "import Prelude hiding (head)", if you substitute other symbols than "head", in at least some cases it will fail: bash$ cat Bug.hs import Prelude hiding (sin) bash$ hmake -hat Bug hat-trans Bug.hs Wrote Hat/Bug.hs /usr/bin/haskell-compiler -c -package hat -o Hat/Bug.o Hat/Bug.hs Hat/Bug.hs:8: Module `Hat.Prelude' does not export `asin' Fortunately there is a reasonably easy work-around for this one: instead of using "import Prelude hiding ...", you can use "import qualified Prelude" and then explicitly qualify all Prelude symbols. -- 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.

2 1

Hat bug report: Ambiguous occurrence `List'
by Fergus Henderson 30 Jun '04

30 Jun '04

I am trying to get Hat working on a reasonably large and complicated project. Unfortunately it doesn't work. I have cut down the code which triggers the problem to the following simple test case: | bash$ cat Foo/List.hs | module Foo.List where | | class List a b where | foo :: a -> b | | main :: IO () | main = return () | | bash$ hmake -hat Foo/List | hat-trans Foo/List.hs | Creating directories Hat Hat/Foo | Wrote Hat/Foo/List.hs | /usr/bin/haskell-compiler -c -package hat -o Hat/Foo/List.o Hat/Foo/List.hs | | 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 I am using hat-2.02.8 with ghc 6.2 on Debian Linux. -- 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.

4 18

Hat bug report: incorrectly lexing "__"
by Fergus Henderson 30 Jun '04

30 Jun '04

Hat mishandles programs containing "__". bash$ cat Foo.hs f :: Int -> Int f __ = 42 bash$ hmake -hat Foo hat-trans Foo.hs Fail: expandTypeSynonym: Int is not a type synonym The problem here seems to be that Hat is lexing "__" as two tokens, rather than one. The Haskell 98 report says | Lexical analysis should use the "maximal munch" rule: at | each point, the longest possible lexeme satisfying the lexeme | production is read. so "__" should be parsed as a single token, not two tokens. Note that in the Haskell 98 grammar, the lexical category "small" includes the underscore character. This bug is very easy to work around, of course. I'm just reporting it for your information. 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.

2 1

Hat bug report: hat 2.02 vs ghc 6.2
by Fergus Henderson 22 Jun '04

22 Jun '04

I tried building Hat 2.02-8 from sources on Debian Linux (testing) using ghc 6.2. It did not compile. I got the following error message: Hat/Foreign/ForeignPtr.hs:89: Variable not in scope: `Foreign.ForeignPtr.foreignPtrToPtr' Hat built OK when configured with "configure --buildwith=ghc5", though. -- 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.

2 2

Support request for compiling hat
by Robert van Herk 18 Jun '04

18 Jun '04

Hi people, As a user of haskell, and as a student in information science at the university of Utrecht, I have been very interested in using hat since a while. However, I cannot get to compile it... First, I tried download the latest releases of ghc, hmake and hat. However, hat refused to compile because it found the ghc version too low (although, in fact, it is probably to new). So, I tried to use the ghc version that the release notes of hat mentioned. However, hmake refuses to compile with this version installed :-(. So, I tried to install BOTH releases of ghc. With this setup, hmake refuses to compile as well... My new approach was to use the latest releases of ghc and hmake again, but try the CVS version of hat. The compiling actually started quite promising, but after a while I got <SNIP> Stop - hmake dependency error. cd src/hattools; make HC=ghc install make[1]: Entering directory `/home/robert/src/hat/src/hattools' hmake -hc=ghc -I. -I/home/robert/src/hat/include -fglasgow-exts -package lang -package util -DUSE_READLINE=1 SrcRefViewer \ -d/home/robert/src/hat/targets/ix86-Linux/obj/hattools Fail: Can't find module System in user directories . . /home/robert/src/hat/include Or in installed libraries/packages at /usr/local/lib/ghc-6.2.1/imports /home/robert/soft/lib/ghc-6.2.1/hslibs-imports/lang /home/robert/soft/lib/ghc-6.2.1/hslibs-imports/util Asked for by: SrcRefViewer.hs Fix using the -I, -P, or -package flags. </SNIP> Could you please help me in trying to compile the hat software? From what I read on the site it is very useful, but I just cannot seem to be able to compile it... Thanx, Robert van Herk

3 2

re: comments on hat 2.02
by Bernard James POPE 12 Mar '04

12 Mar '04

Hi Malcolm, Sorry I didn't get back earlier. I wasn't on the Hat mailing list until recently. > > I discovered that hat doesn't like it if I define a type called "List", > > as in: > > > > data List = List deriving Show > > main = print List > > > My guess is that all imports of Hat's special libraries should be > > qualified imports. > > Yes, and they already are. The problem in this instance is that > the transformed Hat.Prelude is re-exporting Fun, List, Tuple0, etc, > when there is no need (they will always be available qualified from > elsewhere anyway). Unfortunately, the untransformed equivalents > ([],(,),(->)) which give rise to them /do/ need to appear in the > export list of the untransformed Prelude. So there is no immediate > and easy solution to this issue. I see. But couldn't you just hide those things? ie: import Hat.Prelude hiding (List, Tuple... , Fun) > > Another problem I have encounterd is that the trace tools > > exit leaving my terminal in a bad state, namely my terminal does > > not echo its output any more. I have to type "reset" at the > > prompt to get it back. This is on Debian linux with the gnome > > terminal. > > We also use linux (Slackware) with the gnome-terminal. As far as I > am aware, the terminal should be left OK provided the browser exited > normally. If the browser crashes for any reason, it can leave the > terminal settings badly. Are you exiting with a :quit command? It seems that the problem only happens for me with hat-trail. hat-observe does not cause the same thing to occur. I use :q in both cases to quit. I'm using gnome-terminal version 1.4.0.6 I had the same trouble with the readline replacement that comes with GHC: System.Console.SimpleLineEditor which may very well be the editor that hat uses? > > A small gripe is with the extra files that hat puts in the current > > working directory. My preference would be to put everything in > > the Hat subdirectory. Perhaps there is an option to do this? > > Do you mean the .hat, .hat.output, and .hat.bridge files? We could > add an option to place them in another directory I suppose. Yes those files, and .hx if possible. Its a minor issue. > > A more general comment is with the display of functional values. > > The controversy (purely between the developers, of course) is whether > it is useful to show anything in place of the lambda (\...) symbol. > What would you show - the source code? a mapping? Yes, either. Its nice to have the option of both. > * In principle, given a source reference attached to the lambda > in the trace itself, the browser could "snip out" the full > original source expression and insert it into the display. > (We currently only have the source start position, not the full > extent of the expression, but we hope to fix that eventually.) > > But the source code display is already available! (by using a > :source command to open a window with the relevant expression > highlighted). The value of free (lambda bound) vars inside the expression is not available this way, it may be useful to see them. Probably in the hat tools you can get at them via some other route. Perhaps you can record a link to the free vars for the lambda expression in the trail? > * You suggest an "observe"-like mapping as an extensional > representation of the anonymous function. For one thing, such > a mapping could be extremely large. And for another, it should > in principle already be available, by a direct link to hat-observe. It could be large, yes, but so could any value. I think you have to deal with large things anyway, so functions don't make the problem any worse than it already is. For declarative debugging, which is the realm of hat-detect, it is very important to be able to view all higher-order arguments and results, including anonymous functions. Some questions from the debugger can't be answered without this information. My general impression from playing around with this in buddha is that term representations of functional values are okay for simple partial applications and lambda expressions, but for anything else the only comprehensible thing is the map representation. Consider debugging a parser combinator library which is written in monadic style. Underneath each (non-trivial) parser is a mess of lambda abstractions and calls to >>=. You can print this stuff out, but few programmers will have any idea what it all means. The cognitive load is much too high. I think in this situation it is nicer to see the parsers as mappings from inputs to outputs. Thanks for your answers to my questions. Cheers, Bernie.

1 0

caps and hats for your all styles
by fanny 09 Mar '04

09 Mar '04

Dear manager, We are glad to learn about your company is selling in the headwear field, we sent this message and hope that we can serve you in some way with competitive price, prompt delivery service and guaranteed quality. The following is a brief introduction for our company: Our company is a professional and experienced hat-making company that specializes in manufacturing all kinds of headwear with over 20 years history and over 2000 staff members. Our factory located in ShenZhen ,China. We believe that low cost is essential, but the quality of our products is the priority. For the more delails, we welcome you to visit our factory at anytime or visit our web site as below. If you need any samples for your reference ( we take just 4-5 days for sampling). Looking forward to hear you soon with many thanks. Sincerely Fanny Fan fanny(a)scheadwear.com www.scheadwear.com South Of China Headwear Co., Ltd

1 0

Warning: could not send message for past 4 hours
by Mail Delivery Subsystem 07 Mar '04

07 Mar '04

********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Sun, 7 Mar 2004 09:55:05 -0500 (EST) from [217.159.192.32] ----- Transcript of session follows ----- <ail.httpd(a)cno8w9.turner.com>... Deferred: Connection timed out with cno8w9.turner.com. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old

1 0

comments on hat 2.02
by Bernard James POPE 04 Mar '04

04 Mar '04

Hi all, I've been playing with hat 2.02 installed via a debian package. Using ghc 6.02 (I think) to build the transformed code. (Note: I couldn't get it to build on my own with ghc 6.02). I'm not sure if my version has all the latest patches applied to it (somehow I doubt it). I apologise in advance if my comments are covered in the documentation. (I looked, but I didn't see them). I discovered that hat doesn't like it if I define a type called "List", as in: data List = List deriving Show main = print List When ghc tries to compile the transformed code it finds that my List type clashes with one that's coming via the Hat.Prelude. I found that the problem is fixed if I do this in Hat/F.hs: import Hat.Prelude hiding (List, aList) Obviously this is not a general solution. My guess is that all imports of Hat's special libraries should be qualified imports. Another problem I have encounterd is that the trace tools exit leaving my terminal in a bad state, namely my terminal does not echo its output any more. I have to type "reset" at the prompt to get it back. This is on Debian linux with the gnome terminal. A small gripe is with the extra files that hat puts in the current working directory. My preference would be to put everything in the Hat subdirectory. Perhaps there is an option to do this? A more general comment is with the display of functional values. The item: 1. option to show lambda expressions in full appears under the heading "Controversial Wishes". I wonder what it means to be controversial in this case? My general experience with buddha is that term-based representations of functional values are ok when they are small things like partial applications, such as: map (+1) [1,2,3] = [2,3,4] But when the function is a complex thing, such as a nested lambda it can get far too difficult to understand. This occurs a lot in certain styles of programming, like parser libraries (which can be very hard to debug). Generally, I've found that with complicated functions it is much nicer to see them as partial maps, like the way that observe shows functions: map {1 -> 2, 2 -> 3, 3 -> 4} [1,2,3] = [2,3,4] Is it possible to do the same in Hat? One last question is will hat-detect be released again? Cheers, Bernie.

2 1