This is maybe as good a time as any to discuss the usual alternative presentation of transducers that I find is a far gentler introduction.
A transducer is simply a function of the form `a -> List<b>`. Yes this is fully polymorphic, i.e. it holds even for transducers that only operate over just lists.
In this case `mapping` is just
This lens views a transducer through the lens of the `eduction` function as a more souped up `map`. Whereas with a normal `map` you only get to use a function `a -> b`, which means you can't change the underlying structure, with `eduction` you get to use `a -> List<b>` (again a transducer), where you "keep" any elements that are in the output list and you "discard" any elements not in the output list.
So e.g. `mapping` would be:
(defn mapping [f] (fn [x] [(f x)]))
or in Python
def mapping(f):
return lambda x: [f(x)]
and `filtering` would be:
(defn filtering [f] (fn [x] [if (f x) [x] []]))
or in Python
def filtering(f):
return lambda x: [x] if f(x) else []
A transducer is simply a function of the form `a -> List<b>`. Yes this is fully polymorphic, i.e. it holds even for transducers that only operate over just lists.
In this case `mapping` is just
This lens views a transducer through the lens of the `eduction` function as a more souped up `map`. Whereas with a normal `map` you only get to use a function `a -> b`, which means you can't change the underlying structure, with `eduction` you get to use `a -> List<b>` (again a transducer), where you "keep" any elements that are in the output list and you "discard" any elements not in the output list.
So e.g. `mapping` would be:
or in Python and `filtering` would be: or in Python In my opinion way clearer and easier!For more details on the full equivalence see https://news.ycombinator.com/item?id=27778423
The current presentation of transducers has always felt like a wart in Clojure.