- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Exceptions
by Simon Peyton-Jones 05 Oct '04

05 Oct '04

Actually GHC does exactly that when you compile with -prof -auto-all. Then if you run with +RTS -xc, you get a backtrace of sorts. (I have not tested this recently!) The backtrace is not yet reified into a data structure that can be examined, but that'd be quite doable if someone wanted to try. The downside is that -prof makes many optimisations work less well, and all modules must be compiled this way. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of MR | K P SCHUPKE | Sent: 01 October 2004 18:29 | To: alastair(a)reid-consulting-uk.ltd.uk; haskell-cafe(a)haskell.org | Cc: k.schupke(a)imperial.ac.uk; jgoerzen(a)complete.org | Subject: Re: [Haskell-cafe] Exceptions | | >But, being able to see the context in which a thunk was constructed would be | >extremely useful. | | Yes of course... I was thinking along the lines of what is possible, rather | than what is desirable. If only ghc had a -g (debug) flag like gcc that would | force each funtion to push its entry onto some kind of call stack that would | be returned by exceptions... | | Keean. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

3 2

Re: [Haskell-cafe] Optmiization of recursion
by Jon Cast 04 Oct '04

04 Oct '04

Fergus Henderson <fjh-mailbox-18(a)galois.com> held forth: > On 28-Sep-2004, John Goerzen <jgoerzen(a)complete.org> wrote: > > As I'm investigating Haskell, it's occured to me that most of the > > Haskell tutorials out there have omitted something that was quite > > prominent in the OCaml material I had read: making functions properly > > tail-recursive. > > > > The OCaml compiler was able to optimize tail-recursive functions such > > that they could be compiled using a loop. This would achieve two main > > benefits: performance due to not needing to allocate/deallocate stack > > frames, and the ability to work on very large lists since each recursive > > call did not consume extra stack space. <snip> > If analyzing the performance and space usage of your programs is > important, then Haskell may not be the best choice of language. I disagree. If performance and space usage are sufficiently important, Haskell may not be best. But it's really not that much easier to analyze performance or space usage under strict languages. In either case, the golden rule is: profile. Reading the source code will tell you very little. Jon Cast p.s. Of course, I know that reading the source code tells you very little about strict languages and nothing about lazy ones. But in both cases it is overwhelmingly dominated by profiling.

2 1

Predicate logic (FOL) reasoning in Haskell
by Graham Klyne 04 Oct '04

04 Oct '04

I was recently passed this reference, which I thought was worthy of sharing here... I've not yet read it myself in detail, but at a glance it looks very readable. http://staff.science.uva.nl/~bcate/core/rwt.pdf [[ Reasoning with Tableaux Jan van Eijck CWI and ILLC, Amsterdam, Uil-OTS, Utrecht ... The paper contains the full Haskell [5] code of a free variable tableau theorem prover for predicate logic, written in `literate programming' style. ]] #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: [Haskell-cafe] Exceptions
by Dominic Steinitz 02 Oct '04

02 Oct '04

I'd be cautious about using exceptions too liberally. When I implemented a Haskell equivalent to traceroute, I wanted to stop sending packets when a certain condition occurred. It was very tempting to throw an exception and catch it at the top level. However, I think the code below is easier for the maintainer (me) to understand. Dominic. sequenceWhile_ :: Monad m => (a -> Bool) -> [m a] -> m () sequenceWhile_ p [] = return () sequenceWhile_ p (x:xs) = x >>= \c -> if (p c) then sequenceWhile_ p xs else return ()

1 0

Compiling GHC for AIX5.1L
by John Goerzen 01 Oct '04

01 Oct '04

Hello, Following the directions at http://www.haskell.org/ghc/docs/6.2.1/html/building/sec-porting-ghc.html#UN…... I have a Debian unstable system on i386 as the host machine and an IBM PowerPC system as the target. I have configured the files as specified in the docs. I am to the "make boot && make" phase in the ghc directory on the (Linux) host. All goes well until: ==fptools== make all -r; in /home/jgoerzen/no-backup/programs/ghc-6.2.1/ghc/rts ------------------------------------------------------------------------ ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -c Adjustor.c -o Adjustor.o /tmp/ghc10917.s: Assembler messages: /tmp/ghc10917.s:54: Error: no such instruction: `dcbf 0,%eax' /tmp/ghc10917.s:55: Error: no such instruction: `sync' /tmp/ghc10917.s:56: Error: no such instruction: `icbi 0,%eax' /tmp/ghc10917.s:63: Error: no such instruction: `sync' /tmp/ghc10917.s:64: Error: no such instruction: `isync' make[1]: *** [Adjustor.o] Error 1 make: *** [all] Error 1 Why it's trying to use PowerPC assembler on an x86 host I don't know. (I assume that's what's going on here; but I don't really know.) What is the problem?

2 5

Re: [Haskell-cafe] Exceptions
by Niklas Broberg 01 Oct '04

01 Oct '04

Alastair Reid wrote: > > 3. Can I define my own exception types? > >Sadly, no. There is only one 'exception type'. > >You can use dynamics and encode new kinds of exceptions as Strings > but that isn't very satisfactory. But not at all, allowing you to declare your own exception types is *exactly* what using dynamic exceptions is all about. No need for String encodings, we can do far better than that. =) If I have my own type of exceptions, by making that type an instance of Typeable I can use the functions 'throwDyn' and 'catchDyn' instead of the normal 'throw' and 'catch'. That way I can declare exception handlers that only exceptions of a particular type, and just re-raises any other. I could for instance write main = do ... a bunch of computations ... `catchDyn` (\e :: MyExceptionType1 -> ... handle exceptions of MyExceptionType1 ...) `catchDyn` (\e :: MyExceptionType2 -> ... handle exceptions of MyExceptionType2 ...) `catch` (\e -> ... handle exceptions of the built-in Exceptions type ...) (Note that the type annotations on the patterns are not needed if the types can be inferred properly from within the handler. Note also that the Typeable constraint can be automatically derived by ghc with -fglasgow-exts, so no difficulty there either) Check the section about dynamic exceptions at http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control.Exceptio… for more info. > > 4. Can I write code that can catch and handle multiple different > > exception types from a single block of code? > >You use standard Haskell pattern matching so, yes, you can catch multiple >kinds of exceptions. They're not different types though. But yes they are, see above. Or rather, they can be, or they can be constructors of a common user-defined type, combining common pattern matching with dynamic matching on types. =) > > 5. Is there anything different about working with exceptions in monads? > >Use raiseIO instead of raise to raise exceptions. The functions for raising exceptions are called 'throw' and 'throwIO' (and 'throwDyn'), not raise. /Niklas _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Re: [Haskell-cafe] Exceptions
by MR K P SCHUPKE 01 Oct '04

01 Oct '04

>But, being able to see the context in which a thunk was constructed would be >extremely useful. Yes of course... I was thinking along the lines of what is possible, rather than what is desirable. If only ghc had a -g (debug) flag like gcc that would force each funtion to push its entry onto some kind of call stack that would be returned by exceptions... Keean.

1 0

Re: [Haskell-cafe] Exceptions
by MR K P SCHUPKE 01 Oct '04

01 Oct '04

>1. Can exceptions be used in "pure" functions (outside of monads?) Exceptions can be thrown from pure functions, and can be used exactly like in the OCaml example (but in Haskell syntax) Exceptions can only be caught in the IO monad. >2. How are these exceptions caught and handled aside from using bracket? bracket, catch, catchIO >3. Can I define my own exception types? There is a User exception type, I don't think you can define your own completely new exception type. >4. Can I write code that can catch and handle multiple different >exception types from a single block of code? Yes but see (1) only in the IO monad >5. Is there anything different about working with exceptions in monads? No. >6. Can I get a stack trace from ghc or hugs if an exception is never >caught and thus causes the program to terminate? Stack traces in lazy laguages are not very useful. Best work-around is to produce an explicit call trace by inserting prints into functions... obviously this requires the functions to be in the IOMonad. Things are still odd because of lazyness though. Keean.

3 2

Exceptions
by John Goerzen 01 Oct '04

01 Oct '04

One of the most important features of a modern language is, to me, exceptions. I have found very little coverage of exceptions in Haskell, what what coverage there was seemed to be centered on I/O. One reason I'm asking is this: what to do when pattern matching is incomplete due to an error. For instance, this is a common pattern in my OCaml code: let queuedir_of_type t = match t with "foo" -> "/data/queue5" | "bar" -> "/data/queue3" | _ -> raise (Exception ("Invalid type " ^ t));; This is often useful when "t" is something that was originally read from a user. Python has an expressive exception mechanism, where one can catch various different exceptions from a single block of code, etc. So, I have some questions about exceptions in Haskell: 1. Can exceptions be used in "pure" functions (outside of monads?) 2. How are these exceptions caught and handled aside from using bracket? 3. Can I define my own exception types? 4. Can I write code that can catch and handle multiple different exception types from a single block of code? 5. Is there anything different about working with exceptions in monads? 6. Can I get a stack trace from ghc or hugs if an exception is never caught and thus causes the program to terminate? Thanks! -- John

4 3

Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results]
by Greg Buchholz 30 Sep '04

30 Sep '04

Sam Mason wrote: > > You probably want some strictness annotations in there. . . Now we're getting somewhere. When I replace the tuples with my own (strict) data structure, it gets about 7.5 times faster than the original shootout example (or about 24 times faster than the version with tuples). I get another 2x speedup when I pass '+RTS -G1' to the executable. So the version below is about 15 times faster than the original using the 3MB data file from the shootout. (Now we're only about 40x slower than ocaml). Don't forget to turn on '-funbox-strict-fields' for an additional improvement. -- Compile with... -- ghc -O2 -ddump-simpl -fvia-c -funbox-strict-fields -o wc_fold2 wc_fold2.hs -- execute as... ./wc_fold2 +RTS -G1 <input.txt import IO main = do file <- getContents putStrLn $ show (foldl wc (St 0 0 0) file) data Stuple = St !Int !Int !Int deriving Show wc (St l w c) '\n' = St (l+1) w (c+1) wc (St l w c) ' ' = St l (w+1) (c+1) wc (St l w c) x = St l w (c+1) ...It still seems like it's using a lot of memory (or at least doing a lot of garbage collecting). But it it still vastly better than before. Is there any way to reduce this more? (60,000,000 bytes divided by 3,000,000 chars = 20 bytes per char). Here's the memory usage report... 61,387,752 bytes allocated in the heap 11,837,148 bytes copied during GC 99,780 bytes maximum residency (234 sample(s)) 234 collections in generation 0 ( 0.11s) 1 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 0.15s ( 0.15s elapsed) GC time 0.11s ( 0.14s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.26s ( 0.29s elapsed) %GC time 42.3% (48.3% elapsed) Alloc rate 409,251,680 bytes per MUT second Productivity 57.7% of total user, 51.7% of total elapsed Greg Buchholz

1 0