- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>Yes, in principle. But that means you still need to write more and >tedious code to deal with it. Just because code is tedious does not mean it is not necessary to handle all corner cases. A robust application does not fail when given unexpected input. >Are you going to discard lists in favor of tuples, Of course not... You can actually define constrained datatypes where the maximum length is a parameter of the type. Unfortunately in haskell because these values have to be at the type level we end up encoding them as Peano numbers... See Conor McBrides "Faking It" paper for some examples of how to do this. Also see Oleg, Ralf and My paper "Stronly Typed Heterogeneous Lists" to se how far you can get with these techniques (we define a heterogeneous list that can be constrained in many ways, including by length, or content type). I guess in a way you are nearly right as these techniques fundamentaly us binary products like (,) - but thats also exactly what any binary constructor including ':' is anyway... >The only difference is that I want to do it automatically My point was that you can manually label some functions, but to automatically do it for all functions is going to cause big stack space problems - think about recursive functions... or mutually recursive functions... Keean.

2 1

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>Sometimes the qualification of an error changes while it is propagated. There was a discussion about this recently (on the ghc list I think)( The proposed (partial) solution is to use mapException: mapExceptionIO :: (Exception -> Exception) -> IO a -> IO a mapExceptionIO f io = Exception.catch io (\e -> throw $ f e) which would be used like: main = mapExceptionIO (\x -> ErrorCall $ showString "in main: " $ show x) $ do Exceptions can be thrown from anywhere, but can only be caught in the IO monad hence mapException must be in the IO monad. Map exception allows a kind of 'backtrace' allowing all functions in the call stack of a function which throws an exception to annotate the error message. Exceptions should only really be used for unpredictcable events, I find that the defintion of functions like head is lacking rigor... I would prefer to see: head :: [a] -> Maybe a head (a0:_) = Just a0 head _ = Nothing I think functions should only throw an exception if they are subject to the halting problem (the only way to tell if an algorith will fail is to run that algorith) - head and lots of other functions in the prelude are not subject to this, and in my opinion should really be returning Maybe... nobody said anything about me previous post about using the type system to have 'validated' types - does this mean everyone thinks its a good idea, or was it too off topic - too obvious? Keean.

4 3

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>mins = map ((\(x:_)->x).sort) maybe what you meant was: case sort x of (x:_) -> ... do whatever with x ... _ -> ... do failure conition ... As I said, if you can _guarantee_ non failure I guess head is okay, but the fact that this thread started with the observation that the error produced by head is difficault to track dow n we must conclude that programmers make mistakes and cannot be trusted to make such guarantees .... Hence my suggestion to use the type system. Effectively the 'case' forms a guarantee of non-emtyness for the stuff in the case... but you cannot pass this guarantee into functions like 'head' Using the type system to encode such things allows this 'guarantee' to be passed into functions... Keean.

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>As for head, I think it's fine that it throws an error because it is >specified to be defined for only non-empty lists. But surely it is better to encode this fact in the type system by useing a separate type for non-empty lists. >Argh, no! Violating the precondition of head is a bug in the caller, >I want it to crash, Again by encoding this at the type level the compiler can guarantee that that it is not going to crash or return a compile time error... also by forcing the programmer to deliberatly cast to a non-empty list you make explicit the 'non-emptyness'... also the type signature of head contains the 'contract' that the list must be non empty. >A mechanism for a function to report the caller site would obliviate >the need for all this ugliness Unfortunately the cost of this is prohabative as the call stack would have to contain backtrace information. Also due to lazy evaluation the 'call site' may not be what you expect. I guess we just have to disagree I find very little cause to use head. Here's what John Meacham had to say: ----------------------------------- Note that pattern matching rather than deconstruction functions have a number of benefits, not just relating to error messages, consider two functions which use the head of their argument. f xs =3D ... head xs ...=20 g (x:_) =3D ... x ... now, g is superior to f in several ways,=20 1) the error message generated if the pattern fails will have the file name, line number and name of function 2) everything but the head of xs may be garbage collected right away since there is no reference to the rest of the list! This can cure some nasty space leaks and is vital in certain cases.=20 3) even the simplest compiler will realize g is stirct in its first argument and take advantage of the numerous optimizations that entails.=20 A good compiler may figure out 2 and 3 with f, but it can't always, and w= hy take the chance it won't? All of these benefits apply to deconstructing more complicated types too, so using pattern matching for deconstruction is just a good habit to get into. -------------------------------------- Keean.

2 1

Re: [Haskell-cafe] exceptions vs. Either
by David Menendez 04 Aug '04

04 Aug '04

David Menendez writes: > MR K P SCHUPKE writes: > > > I would suggest using the type system as I said earlier so: > > > > toNonEmptyList :: [a] -> Maybe (NonEmpty a) > > toNonEmptyList (a0:_) = Just (NonEmpty a) > > toNonEmptyList _ = Nothing > > > > Then redefine head: > > > > head :: NonEmpty a -> a > > head (NonEmpty (a0:_)) = a0 > > Oleg described a similar technique a few months ago. > > From <http://haskell.org/pipermail/haskell/2004-June/014271.html>: > > |> newtype NonEmpty a = NonEmpty [a] -- the NonEmpty constructor should > |> -- be hidden (not exported from its module) > |> > |> head' (NonEmpty a) = head a -- no error can occur! Can use unsafe > version > |> tail' (NonEmpty a) = tail a -- no error can occur! Can use unsafe > version > |> > |> -- trusted function: the only one that can use NonEmpty constructor. > |> fork_list_len f g x = if null x then f else g (NonEmpty x) > |> > |> revers x = revers' x [] > |> where > |> revers' x accum = fork_list_len accum (g accum) x > |> g accum x = revers' (tail' x) ((head' x):accum) > > We have these equivalences: > > toNonEmptyList == fork_list_len Nothing Just > fork_list_len d f == maybe d f . toNonEmptyList > > I think defining 'toNonEmptyList' in terms of 'fork_list_len' is > cleaner, but that's just my personal taste. (As it happens, I ended up > defining a very similar function 'cons' in my recursion module[1]). > > [1] > <http://www.eyrie.org/~zednenem/2004/hsce/Control.Recursion.html#v% > 3Acons> -- David Menendez <zednenem(a)psualum.com> <http://www.eyrie.org/~zednenem/>

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 03 Aug '04

03 Aug '04

A lot of programming errors come from failure to correctly validate. I remember being taught to validate on input _and_ validate when you use a value. So I would say do both - use maybe for input functions, and exceptions for when you use a value. You can use the type system to make this more efficient. Imagine you want an integer between 10 and 20, you have a function like: newtype ValidInt = Valid Int validateInt :: Int -> Maybe ValidInt validateInt x | x>=10 && x<=20 = Just (Valid x) validateInt _ = Nothing Now when you validate on input - you produce an error if you get "Nothing" and in all the functions you use the value you use ValidInt instead of Int. This way you use the type system to differentiate between a valid int (does not need to be rechecked) and a normal int (which would need to be validated). Of course you must make sure you don't write more than one constructor function for ValidInt. This suggests a form of constrained constructor would be useful... Whilst this can be done in Haskell, it is not easy and involves reifying the value to a type, and using a type class to constrain the data statement. Really here we are dealing with dependant types, and this is much easier in a dependantly typed language like Epigram. Keean.

3 2

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 03 Aug '04

03 Aug '04

>> Is there any easy way (TH?) to amend these to output the line number Or use GHC's reifyLocation 'function' in a mapException. Keean.

1 0

Modifying Running Programs
by S. Alexander Jacobson 02 Aug '04

02 Aug '04

eBay modifies 30k lines of code per week while maintaining 99.92% uptime. Is there a way to force ghc (or some other Haskell implementation) to load new implementations of functions without restarting the program? Alternatively, is there a way of restarting a program with new code without having to reconstruct all its in memory state? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

2 1

Re: [Haskell-cafe] Modifying Running Programs
by MR K P SCHUPKE 01 Aug '04

01 Aug '04

>Is there a way to force ghc (or some other Haskell >implementation) to load new implementations of >functions without restarting the program? Yes, if you use the dynamic loading interface fron ghci. Code can be loaded and unloaded at runtime (however I believe the actual memory is never recovered) Keean.

1 0

Multiprocessor compiling.
by Matthew Roberts 01 Aug '04

01 Aug '04

It seems there is quite some interest in compiling code for multi-processor machines. As a research student, I am always looking for interesting projects to do. However, I am no haskell guru and have certainly never written a compiler. All the comments so far have been very interesting, but too many go over my head and I am not gettting a coherent view of what is going on. Let me try to tie this up. The basic computational model of functional languages seems inherantly parallilisable, but there are clearly many problems - and I don't really understand them. I just picked up the book on implementing the back end of a Haskell compiler and so I will eventually get there. For the meantime, and for all the others out there in my situation, could someone who knows tell us the fundamental reason it is hard to compile Haskell for multiple processor machines - in broad strokes. Cheers, Matt

3 2