functions not in type classes

Cagdas Ozgenc
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 [1]) 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
> using
> 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.
> [1] 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)'.
> ___cheers,_dave_________________________________________________________
>|`...heat generated by its microprocessors will
>|slope upward exponentially, reaching the power
> work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel