
Greetings. Why does Haskell let you write functions that are not a part of type class? For example instead of elem :: Eq a => a -> [a] -> Bool map :: (a -> b) -> [a] -> [b] class Container a where elem :: Eq b => b -> a b -> Bool map :: (b -> c) -> a b -> a c would define methods that can work on all containers, and create a discipline to write more reusable and generic functions. Thanks

On Fri, 18 Jan 2002, Cagdas Ozgenc wrote:
Why does Haskell let you write functions that are not a part of type class?
[snip] Responding to the more philosophical bit rather than the concrete type stuff snipped, I'm not a supporter of the belief that `absolutely everything in all programs ever written in a language should be object oriented', which appears to be what your proposal implies. (Maybe I'm wrong, and I know that, e.g., Ruby supporters disagree with me.) I think there are lots of components of programming where using object-orientation ideas make sense and I use them in those areas when writing my C++ and Haskell programs, but there are also areas where the object orientation leaves things the same or makes them more contrived than otherwise. For example, consider a function casually expressed like -- fn derivative init val result newtonRaphson :: (Float -> Float) -> (Float -> Float) -> Float-> Float OK, it could certainly be generalised to newtonRaphson :: Floating a=> (a->a)->(a->a)->a->a easily enough, but to actually make it a type class method you'd need to make something like class DifferentiableFloatingSingleVarFn which might be sensible for a big library, but not if I just need it just a couple of times in a one off script. Finally, what typeclass should main by a member of, and more importantly what benefit does it provide? :-) ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel
participants (2)
-
Cagdas Ozgenc
-
D. Tweed