- Haskell-Cafe - Haskell.org

Re: exceptions vs. Either
by MR K P SCHUPKE 09 Aug '04

09 Aug '04

>After all, Java basically does exactly what you're asking for with Java's head/tail would be doing runtime checks if they are throwing exceptions, static guarantees mean the program would not be allowed to compile if it broke the static guarantees. >end-programmers have to worry much less about handling errors properly. Which is a bad thing! All programmers always have to consider error conditions, if they don't they write buggy code - that's the nature of the beast. I prefer making programmers expicitly face the decisions they are making, rather than have things implicitly handled in a way that hides what is going on from the programmer. Keean.

5 6

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

07 Aug '04

>Sounds like a job for...Type Inference! In Olegs post where he gave examples of how to make exceptions explicit in type signatures: oleg said: > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > > module TER where > > class CERROR a c where > darn:: a -> c-> String -> b > > instance Show a => CERROR a c where > darn label _ msg = error $ "Error: " ++ (show label) ++ " " ++ msg > > > data EHead = EHead deriving Show > data ETail = ETail deriving Show > data EJust = EJust deriving Show > > myhead x@([]) = darn EHead x "head of an empty list" > myhead (x:_) = x > > mytail x@([]) = darn ETail x "tail of an empty list" > mytail (_:xs) = xs Now, if we ask GHCi for the type of myhead, we get *TER> :t myhead myhead :: forall a. (CERROR EHead [a]) => [a] -> a ---------------------------------------------------------- As you can see you get the advantage of explicit exceptions, but with type inference. Keean.

1 0

Re: [Haskell-cafe] Type classes... popular for newbies, isn't it?
by Arjun Guha 07 Aug '04

07 Aug '04

I'd rather not do that, but even if I did, the type-variable action would not be reachable in the terminal function. I could specify a functional dependency st -> action (though I've never used it, it would be a fun to learn). I'm curious as to why my class declaration compiles in GHC, as there doesn't seem to be any way to use it. -Arjun On Aug 7, 2004, at 01:06, camarao(a)dcc.ufmg.br wrote: > Hi Arjun. > > How about inserting one more parameter, "action", in your class > definition: > > class (Ord st) => MinimaxState st action where > successors:: st -> [(action,st)] > terminal:: st -> Bool > > instance MinimaxState Int Int where > terminal i = i == 0 > successors i = [(1,i+1), (-1,i-1)] > > Then don't forget to start the compiler/interpreter with > -fglasgow-exts. > > Hope this helps. > > Regards, > > Carlos > >

4 3

Type classes... popular for newbies, isn't it?
by Arjun Guha 07 Aug '04

07 Aug '04

This class definition is giving me a lot of problems with the successor function: class (Ord st) => MinimaxState st where successors:: st -> [(action,st)] terminal:: st -> Bool A trivial example would be: instance MinimaxState Int where terminal i = i == 0 successors i = [(1,i+1), (-1,i-1)] However, I get this error in GHC: Could not deduce (Num action) from the context (MinimaxState Int, Ord Int) arising from the literal `1' at AbTest.hs:7 Probable fix: Add (Num action) to the class or instance method `successors' In the first argument of `negate', namely `1' In the list element: (- 1, (- i) - 1) In the definition of `successors': successors i = [(1, i + 1), (- 1, (- i) - 1)] I have the class definition and the instance definition in seperate files. I don't understand where I'm supposed to put the "probable fix." I don't want it to be in the class definition, since action should be fairly arbitrary. In fact, no matter what I try, I get errors, for example: instance MinimaxState Int where terminal i = i == 0 successors i = [("action",i+1), ("action",i-1)] Cannot unify the type-signature variable `action' with the type `[Char]' Expected type: action Inferred type: [Char] In the list element: ("action", i + 1) In the definition of `successors': successors i = [("action", i + 1), ("action", (- i) - 1)] Any suggestions? -Arjun

3 2

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

07 Aug '04

>You should include the definitions of the classes before saying HOrderedList l' just has to prove by induction that for any element in the list, the next element is greater, so the class is simply: class HOrderedList l instance HNil instance HCons a HNil instance (HOrderedList (HCons b l),HLe a b) => HCons a (HCons b l) which is the equivalent type level program to ordered :: [Int] -> Bool ordered [] = True ordered [a] = True ordered (a:(b:l)) = if a<=b then ordered (b:l) else False ordered _ = False It is obvious by observation that the a<=b ensures order. This is a lot simpler than say a heap-sort. I suppose you could contend that there are some classes above I still haven't defined - but you wouldn't expect to see definitions for (<=) which is defined in the prelude. Of course to show statically that order is preserved the 'value' of the elements to be ordered must be visible to the type system - so the values must be reified to types... This can be done for any Haskell type, but for numbers we would use Peano numbers - the HLe class for these is again easily defined by induction: class HLe n n' instance HLe HZero HZero instance HLe x y => HLe (HSucc x) (HSucc y) Keean.

5 6

Re: [Haskell-cafe] closed classes
by MR K P SCHUPKE 06 Aug '04

06 Aug '04

Closed t => ???? You want a closed type? The parameter to a class is a type... Actually if you allow undecidable instances you can use the generic instance to close the class class OnlyInt a instance OnlyInt Int instance Fail () => OnlyInt x Where Fail is a class with no instances, that is not exported! If you try and add an instance to OnlyInt the program will fail with overlapping instances. Keean.

2 1

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

06 Aug '04

>class HLe n n' >instance HLe HZero HZero >instance HLe x y => HLe (HSucc x) (HSucc y) Erm of course this was the definition for Equals, not less than or equals! class HLe n n' instance HLe HZero x instance HLe x y => HLe (HSucc x) (HSucc y) Is the definition for less than or equals... but it took me all of 5 seconds to realise the first definition I gave was wrong - because it is so simple... Keean.

1 0

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

06 Aug '04

>>Static guarantees are great, but if you have to explicitly change your >>style of coding to cope with those extra constraints, it can become (very) >>cumbersome. I had to change coding style moving from imperative to declarative languages, but I think it was worth it... Likewise I think having the ability to make strong static guaranees is worth it - you may not, which is why it is important not to break any existing programs with language extensions (if any are necessary). My programs will have less bugs though! >"worse-is-better, even in its strawman form, has better survival I fully subscribe to the 'worse is better' approach, but I don't see how it contradicts the principle of static guarantees - you can have both. Simplicity is about algorithmic complexity not about whether type signatures are provided by the programmer. Infact type signatures are in themselves an embodyment of the simple is better principle. A type signature expresses certain static guarantees about the function in a vary compact way. Consider the sort example... being able to declare a type signature on a sort algorith that enforces ordering of the output would prove the sort algorithm can _only_ output correctly sorted lists under _all_ circunstances. This type signature is much simpler than the actual sort - hence is useful. sort :: (HList l,HOrderedList l') => l -> l' Nice and readable, and much simpler than the actual algorithm (be it bubble sort, or a quick sort) Keean.

2 1

Re: exceptions vs. Either
by MR K P SCHUPKE 06 Aug '04

06 Aug '04

What can I say... Static typing guarantees is what made me switch from object oriented languages like C++/ObjectiveC/Java (that and the availability of a good compiler) - So I am obviously in favour of more static guarantees - I believe programming by contract is the way to reliable _engineered_ software, so the more contractual obligations that can be concisely and clearly expressed in the type system the better. I think Haskell should support dependant types, after all if you don't want to use them you don't have to... (backwards compatability and all that) although it would be useful to have a replacement prelude that used dependant types versions of head etc... I have a hard time understanding why functional programmers would not want more static typing guarantees, after all they can always use C if they dont like type systems! Keean.

5 4

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

06 Aug '04

>Not so. In Java, the programmer is forced to handle most exceptions I forgot you had to do that... Exceptions are explicit in the type signatures. I think Oleg posted a message a while back about how to make exceptions explicit in haskell type signatures... But I would rather use static guarantees where possible, and exceptions where necessary. I haven't really tried using the techniques for explicit exceptions, but on consideration I might see if it is practical to code in that style... Keean.

1 0