On 08/11/06, Ashley Yakeley
Nils Anders Danielsson wrote:
The deadline for discussion is tomorrow, but in case anyone complains I thought I'd summarise the previous discussion already today.
* Consensus was reached that a module containing on plus some functions from the prelude should be added.
That's S of SKI, isn't it? Looks good, as we already have "const" and "id".
* The module name Control.Function was not well received. A bunch of other names were suggested, and almost everyone accepted Data.Function.
If we're creating Data.Function, can we add an "instance Functor ((->) a)" to it? I seem to remember it's currently in an odd place. Or maybe we should create a Data.Functor module.
-- Ashley Yakeley
Actually, the Functor and Monad instances for ((->) a) are somewhat fundamental and I'd personally like to have them available from the Prelude, but I suppose Data.Function would be fine. One interesting thing which we noticed on the IRC channel the other day is that if one is willing to permit a little more polymorphism than at first comfortable, it's possible not only to unify {map, fmap, liftM, liftA}, but function composition as well! We could have class Functor f where (.) :: (a -> b) -> (f a -> f b) The instance for ((->) a) taking care of the ordinary composition case. This would also allow things like square . [1,2,3,4,5] = [1,4,9,16,25] which is somewhat friendly to the view that (fully defined) lists are like functions on the domain of their indices. Function composition, and functor application both hold such a high place in functional programming that it seems a bit strange to unify them at first, but it's certainly nice to know that one could do so. I'll admit that this notation starts getting bizarre when one starts writing down the laws which must be satisfied... (.) (f . g) = (.) f . (.) g or perhaps even more frightening: ((f . g) .) = (f .) . (g .) I believe I even scared xerox with that one. :) - Cale