> 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. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
