Another thing, while toying, I found out that a comparison (n <= 0) takes three reductions more than (n < 1) according to my hugs, so changing the definition of splitAt thus, we require (3*n) reductions less. But the number of reductions and speed are different things, as witnessed by the above, so would it be an improvement to replace "n <= Integerliteral"-queries by "n < Integerliteral"-queries or doesn't that make any difference at all in execution time?
I don't know about in Hugs, but in (compiled, optimized) GHC it should make no difference. Presumably, if you are running something in an interpreter micro-optimizing isn't worthwhile.
Finally, in several contexts I needed to cons an element to one of a pair of lists, so I defined
infixr 5 &,§
(&) :: a -> ([a],[b]) -> ([a],[b]) x & (xs,ys) = (x:xs,ys)
(§) :: b -> ([a],[b]) -> ([a],[b]) y § (xs,ys) = (xs,y:ys).
Well, to start, the type signatures are unnecessarily restrictive. Then, the function that also is not in the Report, but does come up quite a bit by people who get into a point-free or categorical style is the bifunctor, (***) :: (a -> b) -> (c -> d) -> (a,c) -> (b,d) f *** g = \(a,b) -> (f a,g b) this is an instance of (***) in Control.Arrow, hence the name. So, your first function is, (&) x = (x:) *** id or using another function from Control.Arrow, (&) x = first (x:) I can say that I have wanted (***), I can't say that I've ever wanted your two functions. Also, first (x:) seems to be more self-documenting.