functions not in type classes
Fri, 18 Jan 2002 14:30:19 +0200
Thanks. I am quite convinced actually (no sarchasm involved).
> On Fri, 18 Jan 2002, Cagdas Ozgenc wrote:
> > > the goal of type class is to allow overloading of function, so for
> > > id x = x is not subject to overloading => no use to put it in a
> > class.
> > Because it doesn't do anything?
> I believe that (assuming of course that you aren't a simplicity fanatic
> who programs only using the S, K, I combinators ) id is useful for
> interfacing with very general functions which have an a->a argument which
> isn't necessary for what you're doing, e.g.,
> altSumsTransformedList :: (a->a) -> a-> [a] -> a
> altSumsTransfromedList f e (x:xs) = f x - altSumsTransfromedList f e xs
> then you can get the simple alternating sum of the original list simply by
> altSumsTransfromedList id
> A much more commonly used example is
> flip f x y = f y x
> which doesn't seem to do much, but is actually very useful for things
> use in things like foldr when you've already got a function which does
> almost what you want but expects its arguments in the opposite order to
> the one that foldr gives them in. These small functions are very useful,
> and several of them have counterparts in the C++ STL binders.
>  this is a bad joke reference to the fact that `all functional programs
> (under an appropriate encoding of the data) can be converted to an
> equivalent form using just three elementary combinators, S (aka succ), K
> (aka const) and I (aka id)'.
> www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will
> email:email@example.com|slope upward exponentially, reaching the power
> work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel