Is it correct to say that the relationship between the new forms of map/filter/etc, reduction functions, and transducers is something like this:
"traditional" (map f l) is equivalent to (foldl (mapR f) l ), where (mapR f) is the "reduction function" corresponding to map. (mapR would still be list specific)
the new (map f) is a transducer that takes a reduction function and returns another reduction function; given idR, the "identity reduction function" for foldl such that (foldl idR l ) = l, ((map f) idR) = mapR.
Furthermore, given reduction functions mapRR such that (foldr (mapRR f) l ) == (map f l) and idRR such that (foldr idRR l ) = l, then ((map f) idRR) = mapRR. (Because all the list-specific things in the output reduction function come from the input reduction function, the transducer (map f) doesn't need to know anything about lists, so can be used in other contexts as well -- one minor-but-perhaps-easier-to-illustrate aspect of that is, even when used with lists, (map f) is independent of the folding direction, unlike the reduction functions mapR and mapRR.)
(I know this is barely even scratching the surface of the applications, but I'm trying to confirm that I've got the concept right.)
so Functors (fmap)? fmap still uses regular old fns, no machinery.
- reducers can work on tree structures, and thus can exploit parallelism. This would be like using a map that requires only the Foldable typeclass
- In Haskell you have stream/vector fusion, but it's not obvious to know when ghc will actually exploit it, you might want to use something like Control.Monad.Stream or Data.Vector. In theory it might be generalized to all Foldables, but in practice for now it might be a good enough compromise to stick to a limited number of types (the one that support such transducers)
So: nothing terribly new/groundbreaking, but it might bring something like stream fusion to the masses (of clojure developers :P )
type Iteratee el m a -- a processor of 'els' in the monad 'm' returning a type 'a'
type Enumerator el m a = Iteratee el m a -> m (Iteratee el m a)
We called the bits in the middle "step functions" , which could be combined with "consumers", "producers" and "transformers".
And the algebra generalizes hugely (not just collections) but to things like concurrent processes, data flow programs etc.
Things to think about in a non-Haskell settings: how do you prevent reordering side-effects? Can execeptions/non-termination being reordered be observed?
(And if you say "deferring an action is just another term for 'functions'" then that's exactly the point, lifting more algorithmic logic into composable functions)