July 2006 - Haskell-prime

Exceptions
by John Goerzen 07 Sep '06

07 Sep '06

Hello, One thing that bugs me about Haskell is that exceptions are not extensible. I don't know how to craft a good solution, but perhaps if I explain the problem well, someone would come up with one. In a language such as Python or Java, and exception is an object. Let's consider Python for a quick example. Python has an IOError exception. So if I want to write a handler that deals with IOErrors, that's easy enough. Now maybe I want to do something like report socket errors specially. I could define a SocketError class that subclasses IOError. I could take this further, and define a URLError that subclasses SocketError. Now the beauty of it is that I can: * Have a handler that catches URLErrors only and does nothing special with SocketErrors or IOErrors. * Have a handler -- perhaps not even mine -- that catches and works with IOErrors. Since SocketError and URLError are descendants of IOError, that handler will *automatically* work if I raise a SocketError or a URLError. I can see no such mechanism in Haskell. Haskell's I/O exceptions have a certain defined set of errors that they can report, and I can't subclass them and make them more specific for my purposes if I want. Ditto for all the others. The Dynamic exception support is necessary and good to have, but it also under-documented and can be complex. And of course, they still suffer from the same lack of extensibility Are there any suggestions on how we might improve this situation in Haskell? -- John

6 12

Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
by Robert Dockins 28 Jul '06

28 Jul '06

On Jul 28, 2006, at 12:32 AM, Mike Gunter wrote: > Thanks for the answer. (And doubly thanks for giving the answer I > hoped for!) > > I propose that ifThenElse and thenElseIf be added to the Prelude for > Haskell'. While these names are a bit long, I think we want both > functions and these names make the behaviors clear (to me, at least). > > Comments? If we're planning on adding some boolean stuff to the Prelude, I'd like to suggest we add: bool :: a -> a -> Bool -> a bool f t b = case b of { False -> f; True -> t } Why? Because we already have the "maybe" and "either" functions in the prelude which are the catamorphisms on their respective types. While we're at it, we might as well throw in (ordering :: a -> a -> a -> Ordering -> a) as well. That would mean all the algebraic types defined in the Prelude also have their catamorphisms defined (eh, except for n-tuples where n>2, sigh... I guess one could add uncurry3, uncurry4, etc....). On an almost completely unrelated note, I've sometimes thought that it would be nice to be able to have the compiler auto-magicly generate catamorphisms for datatypes upon request. No, I haven't thought out the details. > -m > > > Paul Hudak <paul.hudak(a)yale.edu> writes: > >> Mike Gunter wrote: >> >>> I had hoped the "History of Haskell" paper would answer a question >>> I've pondered for some time: why does Haskell have the if-then-else >>> syntax? The paper doesn't address this. What's the story? >>> >>> thanks, >>> -m >>> >>> >> Thanks for asking about this -- it probably should be in the paper. >> Dan Doel's answer is closest to the truth: >> >> I imagine the answer is that having the syntax for it looks >> nicer/is >> clearer. "if a b c" could be more cryptic than "if a then b >> else c" >> for some values of a, b and c. >> >> except that there was also the simple desire to conform to convention >> here (I don't recall fewer parentheses being a reason for the >> choice). >> In considering the alternative, I remember the function "cond" being >> proposed instead of "if", in deference to Scheme and to avoid >> confusion with people's expectations regarding "if". >> >> A related issue is why Haskell does not have a "single arm" >> conditional -- i.e. an "if-then" form, which would evaluate to bottom >> (i.e. error) if the predicate were false. This was actually >> discussed, but rejected as a bad idea for a purely functional >> language. >> >> -Paul Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 1

[Fwd: Numeric Class reworking]
by isaac jones 27 Jul '06

27 Jul '06

Forwarding a message that was sent to me. Vivian, probably it bounced because you're not subscribed to the list? Thanks for sending it along. Anyone replying, please keep Vivian in the CC. peace, isaac

2 1

RE: deeqSeq proposal
by Simon Marlow 06 Jul '06

06 Jul '06

On 04 April 2006 19:53, Andy Adams-Moran wrote: > Andy Gill wrote: >> let xs' () = 1 : 2 : xs' () >> let xs2 = xs' >> >> let xs = 1 : 2 : xs >> >> So deepSeq xs2 ==> _|_, but deepSeq xs ==> xs Yes, and hence deepSeq isn't monotonic. That's bad. >> I appeal to the "morally correct reasoning" argument .. If the >> program terminates, then it is still correct. The deepSeq is an >> assertion about the ability to represent the result in finite space. > > I'm not convinced Simon's argument holds, as I don't think you can use > deepSeq to write a Haskell function that will distinguish cyclic > structures from infinite ones. If we can't do that, then we haven't > really added any new semantic observational capability to the theory, > so I think the "morally correct reasoning" argument holds. > > Simon? I think we should be able to rely on a bit more than "moral correctness" :-) Imagine writing a denotational semantics for deepSeq: you can't without talking about representations, and we don't want to talk about representations in denotational semantics, or in the Haskell language definition. The only thing you can do with non-functions is put them in the sin bin: deepSeq :: a -> IO () Cheers, Simon

4 4

Nested Guards
by Bas van Dijk 03 Jul '06

03 Jul '06

Hello, I would like to propose a feature from the FP language Clean[1] called Nested Guards. Example from [2]: example arg1 arg2 | predicate11 arg1 | predicate21 arg2 = calculate1 arg1 arg2 | predicate22 arg2 = calculate2 arg1 arg2 | otherwise = calculate3 arg1 arg2 | predicate12 arg1 = calculate4 arg1 arg2 I think the semantics are clear enough. Nested Guards should also be interoperable with Pattern Guards[3]. When a match on a pattern guard succeeds the environment is updated with the new bindings. Then the potential nested guards are matched in order in this new environment. What do you think? Bas van Dijk. [1] http://www.cs.ru.nl/~clean [2] ftp://ftp.cs.kun.nl/pub/Clean/Clean20/doc/CleanRep2.0.pdf (See 3.3 Guards) [3] http://hackage.haskell.org/trac/haskell-prime/wiki/PatternGuards

3 5