June 2004 - Haskell - Haskell.org

NEW DEADLINE: MKM 2004 - CFP (Bialowieza, Poland)
by Roman Matuszewski 25 Jun '04

25 Jun '04

Please post - apologies for multiple copies. ============================================ *** NEW DEADLINE: May 15, 2004 *** MKM 2004 Third International Conference on MATHEMATICAL KNOWLEDGE MANAGEMENT http://mizar.org/MKM2004 September 19 - 21, 2004 Bialowieza - Poland (organized by University of Bialystok) CALL FOR PAPERS Mathematical Knowledge Management is a new field in the intersection of mathematics and computer science. We need new techniques for managing the enormous volume of mathematical knowledge available in current mathematical sources and making it available through the new developments in information technology. A list of topics (to be understood as specialized to the realm of mathematical information) comprises but is not restricted to: Knowledge representation Repositories of formalized mathematics Metadata Deduction systems Datamining Computer Algebra Systems Digital libraries Authoring languages and tools Searching and retrieving Interactive learning Languages of mathematics Web presentation of mathematics Math assistants MathML- and XML-based standards SUBMISSION To submit your paper go to MKM 2004 electronic submission site: http://mizar.uwb.edu.pl/CyberChairMKM/ The deadline for submissions is May 15, 2004. Submitted papers should not exceed 15 pages, must be original and not submitted for publication elsewhere. All papers submitted to the Conference will be reviewed. Accepted papers will appear in the proceedings before the Conference. PROCEEDINGS We plan to publish the proceedings of the Conference in the Springer-Verlag Lecture Notes in Computer Science series (http://www.springer.de/comp/lncs/) Submitted papers must be prepared according to "Authors Instructions of LNCS" (http://www.springer.de/comp/lncs/authors.html) We strongly encourage the author(s) to use LaTeX. Authors of accepted papers are expected to present their work at the conference. IMPORTANT DATES NEW Submission Deadline: May 15, 2004 Notification of acceptance/rejection: June 10, 2004 Camera ready copies: July 1st, 2004 Conference: September 19 - September 21, 2004 AFFILIATED WORKSHOPS - September 18, 2004 - Mathematical User-Interfaces, organized by Paul Libbrecht, - 30 Years of Mizar, organized by Grzegorz Bancerek. PROGRAM COMMITTEE Andrzej Trybulec, Univ. of Bialystok, Poland (Chair) Andrew A. Adams, University of Reading, U.K. Andrea Asperti, University of Bologna, Italy Bruno Buchberger, RISC Linz, Austria Roy McCasland , U. of Edinburgh, U.K. James Davenport, University of Bath, U.K. William M.Farmer, McMaster University, Canada Herman Geuvers, Katholieke U. Nijmegen, NL Therese Hardin, Pierre & Marie Curie U., France Fairouz Kamareddine, Heriot-Watt U., U.K. Michael Kohlhase, Internat. U. Bremen, Germany Paul Libbrecht, Saarland University, Germany Bengt Nordstrom, Chalmers U. of Techn., Sweden Renaud Rioboo, Pierre & Marie Curie U., France Bernd Wegner, Technical U. of Berlin, Germany RELATED LINKS MKM Consortium, http://monet.nag.co.uk/mkm/consortium.html MKM 2001, http://www.risc.uni-linz.ac.at/institute/conferences/MKM2001/ MKM 2003, http://www.cs.unibo.it/MKM03/ MKM NET, http://monet.nag.co.uk/mkm/ MKM Symposium 2003, http://www.macs.hw.ac.uk/~fairouz/mkm-symposium03/ NA-MKM 2002, http://imps.mcmaster.ca/na-mkm-2002/ NA-MKM 2004, http://imps.mcmaster.ca/na-mkm-2004/ ================================================================== Questions should be sent to Conference Chair: Roman Matuszewski, mailto:romat@mizar.org http://mizar.org/people/romat/

1 2

RE: [Haskell] modern language design, stone age tools
by Simon Peyton-Jones 24 Jun '04

24 Jun '04

Switching on profiling (-prof -auto-all) does essentially just this. The cost centre stack is just like an implicit parameters, only one that does not show up in the types. Since there really is some extra parameter passing going on, you really do need to recompile (all) the code. That's a nuisance, but it's a price that I can't see how to avoid in a call-by-need language. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Alastair Reid | Sent: 23 June 2004 21:44 | To: S. Alexander Jacobson | Cc: haskell(a)haskell.org | Subject: Re: [Haskell] modern language design, stone age tools | | On Wednesday 23 June 2004 20:38, S. Alexander Jacobson wrote: | > It would be really nice if you could pass an | > error message down to every function that might | > fail. e.g. using implicit parameters*: | > | > myFunc 0 x = head x with ?failMsg="myfunc 0 caused the error" | | Interesting. Two variations on that: | | 1) Getting a 'stack' trace (i.e., a list of ancestors) can be more | useful than just knowing the immediate ancestor so you might want | myFunc to also take an implicit parameter and to add that | parameter to what it says: | | myFunc 0 x = head x | with ?failMsg="myfunc 0 caused the error but myFunc was called because " | ++ ?failMsg | | [I can't remember if with acts as a let or a letrec. The intention is | to use the ?failMsg passed implicitly to myFunc] | | 2) If you don't want to put errors in the type system, you could instead use | exceptions something along the lines of: | | myFunc 0 x = mapException | (\ err -> show err ++ "when invoked by myFunc 0") | (head x) | | [Not quite type correct but hopefully clear enough. The idea is to combine | the exception value returned with some extra information about the context | with the idea that whoever called myFunc might add extra information. | Ideally, the Exception type would be recursive so we could build chains of | exceptions without having to use Show.] | | -- | Alastair Reid | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 1

RE: [Haskell] modern language design, stone age tools
by Simon Marlow 24 Jun '04

24 Jun '04

On 24 June 2004 11:54, MR K P SCHUPKE wrote: > With reference to "mapException", I thought this seemed a good idea. > I like the 'AnnotatedException' idea... this is much better than > concatenating strings... However for not I thought I would test it > as is, but it doesn't work as I thought - perhaps someone could > point out where I have gone wrong. > > 1) this works: > > main :: IO () > main = do > a <- getLine > hPutStrLn $ showInt (fst . head . readDec $ a :: Int) > `Exception.catch` (\e -> throw $ ErrorCall $ showString "Urk :" $ > show e) > > 2) this doesn't work: > > main :: IO () > main = mapException (\x -> ErrorCall $ showString "Urk :" $ show x) $ > do a <- getLine > hPutStrLn $ showInt (fst . head . readDec $ a :: Int) This is due to the nature of exceptions in Haskell. Evaluating the expression (do a <- getLine; hPutStrLn ...) does not do any IO, and it doesn't raise any exceptions, so the mapException doesn't get to annotate any exceptions. What you really wanted here was (untested) mapExceptionIO :: IO a -> (Exception -> Exception) -> IO a mapExceptionIO io f = catch io (\e -> throwIO (f e)) probably we should have this in Control.Exception too. Cheers, Simon

2 1

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 24 Jun '04

24 Jun '04

With reference to "mapException", I thought this seemed a good idea. I like the 'AnnotatedException' idea... this is much better than concatenating strings... However for not I thought I would test it as is, but it doesn't work as I thought - perhaps someone could point out where I have gone wrong. 1) this works: main :: IO () main = do a <- getLine hPutStrLn $ showInt (fst . head . readDec $ a :: Int) `Exception.catch` (\e -> throw $ ErrorCall $ showString "Urk :" $ show e) 2) this doesn't work: main :: IO () main = mapException (\x -> ErrorCall $ showString "Urk :" $ show x) $ do a <- getLine hPutStrLn $ showInt (fst . head . readDec $ a :: Int) Keean. (using GHC-6.2)

1 0

RE: [Haskell] modern language design, stone age tools
by Simon Marlow 24 Jun '04

24 Jun '04

On 24 June 2004 10:31, Alastair Reid wrote: >> [...] >> 2. Use the mapException trick to annotate exceptions as they >> travel up the stack (see Alastair Reid's message). [...] >> (2) requires that you add lots of annotations to your code, so it's >> not entirely satisfactory for that reason. > > Would it be possible to generalise ghc's -prof-all mechanism so that > annotations could be added automatically. For example, suppose I have > an annotation function > > Debug.Callstack.callstack :: ModuleName -> LineNumber -> a -> a > > Then, if I compile with: > > ghc -annotate=Debug.Callstack.callstack Foo.hs > > then ghc could add > > import Debug.Callstack(callstack) > > to the import list and transform every top level function body > as follows: > > foo (x:xs) = .. > foo [] = ... > => > foo arg = callstack > "Foo" -- module name > 42 -- line number > (foo' arg) > foo' (x:xs) = .. > foo' [] = .. Yes, this could be done. I should have mentioned though: this technique gives you the lazy call stack, whereas what you probably want is the strict call stack (which is what GHC's profiler tries to give you). Getting the lazy call stack is easy from a debugger, we don't need to annotate the program to do that, but we might want to add source locations in the form of debug info to the object file in a similar way to C compilers. It may be that giving programmers access to the lazy call stack is a heck of a lot better than nothing. Cheers, Simon

1 0

RE: [Haskell] modern language design, stone age tools
by Simon Marlow 24 Jun '04

24 Jun '04

On 23 June 2004 18:39, Fergus Henderson wrote: > On 23-Jun-2004, MR K P SCHUPKE <k.schupke(a)imperial.ac.uk> wrote: >> This may not be the right answer to the question (which is of >> course lets write a debugger) - But I have never used a debugger, >> and find them more or less the most unfriendly and useless things > > So how do you debug problems like "Prelude.head: empty list" > in large programs? The two most useful techniques, both have which have already been suggested by others are: 1. Compile with -prof -auto-all and run with +RTS -xc. 2. Use the mapException trick to annotate exceptions as they travel up the stack (see Alastair Reid's message). (1) doesn't work that well, as you noticed. For example, sometimes the exception will stop at a CAF, due to the way cost centres work in GHC. I'd really like us to do better here - keeping track of the call stack in a lazy higher-order language has turned out to be surprisingly tricky. (2) requires that you add lots of annotations to your code, so it's not entirely satisfactory for that reason. Even if we had an interactive debugger, getting a good call stack is still going to be a hard problem. Cheers, Simon

2 1

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 24 Jun '04

24 Jun '04

>Thank you for the programming practice recomendation, Sorry if it seemed like that... I was really trying to suggest practical measures that someone could use in the absence of a debugger - but I do feel that 'commercial quality' code should be bullet proof, and of a different calibre to code for personal use, or academic research. Keean.

2 1

Re: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 23 Jun '04

23 Jun '04

>So how do you debug problems like "Prelude.head: empty list" >in large programs? I normally dont use head, but instead code: case x of (a0:_) -> <expr1> _ -> fail <debug info> for precisely this reason - and the fact that I dont like bindings that can fail... Keean.

2 1

Re: [Haskell] modern language design, stone age tools
by Fergus Henderson 23 Jun '04

23 Jun '04

On 23-Jun-2004, Hal Daume III <hdaume(a)ISI.EDU> wrote: > On Wed, 23 Jun 2004, Fergus Henderson wrote: > > > On 23-Jun-2004, MR K P SCHUPKE <k.schupke(a)imperial.ac.uk> wrote: > > > This may not be the right answer to the question (which is of > > > course lets write a debugger) - But I have never used a debugger, > > > and find them more or less the most unfriendly and useless things > > > > So how do you debug problems like "Prelude.head: empty list" > > in large programs? > > Wasn't addressed to me, but here's what I do: > > write the following function: > > head_ x [] = error ("head_: " ++ show x) > head_ _ l = head l > > and then replace each occurance of "head" with "head_ 1" or "head_ 2" > etc., so I can know where it failed. Well, there are quite a lot of such occurrences in the code that I'm working on: bash$ find . -name \*.hs -o -name \*.lhs | xargs grep -w head | wc -l 130 Replacing all of those occurrences by hand is going to be very very tedious and somewhat time-consuming. Doing it with a script would be better, but that's not a trivial task. Even once that is done, there's no guarantee it will actually help to find the problem. After all, the problem might well be arising from a call to "head" in one of ghc's standard libraries: bash$ find ~/ghc6-6.2/hslibs \*.hs -o -name \*.lhs | xargs grep -w head | wc -l 104 So not only do I have to edit my own code, and the libraries written by my colleagues, I also need to edit the ghc library code, and figure out how to build and reinstall the ghc libraries. That could take a long time. After all that, hopefully I will finally know which function called "head" with an empty list. But even then there's still no guarantee that I've actually found the source of the problem; the real problem might be in that function's caller, or the caller's caller, etc. So I might have to go through the whole process again. > (it is rather sad that this is the best approach i could come up > with...basically tries to get around the [lack of/uselessness of/inability > to use with ghci] stack traces) Yes :-( -- 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 3

RE: [Haskell] modern language design, stone age tools
by MR K P SCHUPKE 23 Jun '04

23 Jun '04

This may not be the right answer to the question (which is of course lets write a debugger) - But I have never used a debugger, and find them more or less the most unfriendly and useless things You either end up single stepping through a million lines of code, or you find the error is of a complex non-localised kind anyway. I find inserting my own debug code into an application to be a much more fruitful way of keeping track of errors. Using conditional compiliation all this extra code can be removed from a finished app. The only problem with this approach in Haskell is that you sometimes have to lift a function into the IO monad for debugging... Keean.

4 3