3 ms·
OK. It's a better map that can keep some state. (I scanned not read your doc and that was my takeaway; I have not thought about what I can do with state yet, pa
by mcbrit 3y ago
OK. It's a better map that can keep some state. (I scanned not read your doc and that was my takeaway; I have not thought about what I can do with state yet, particularly since I had never associated transducers with being able to keep state)
Can you give me an example of a classic problem (since we're talking about transformations, raytracers and compilers come to mind) where if you involve a transducer vs a map you get an interesting difference?
Edit: 'How state is kept is not specified': I assume that there are limitations to state keeping, particularly with the composability and performance pillars of transducers, but I'm just having a really hard time synthesizing everything.
- bjoli 3y agoYou could keep the state using the state monad, or by letting every reducer keep a transparent state in a linked list that whoever is pushing values through it has to handle. The reference implementation keeps it hidden using closures. This is mostly an API thing. In clojure you can pass a transducer when you create a channel. That way you can make a channel do just about anything. Send data in chunks of N. Filter Odd numbers. Or just do arbitrary transformations. It is a protocol for composable transformations of data being passed in one direction. It is not fancy. Not really hard to understand. A generalization of map, filter, and friends.
- bjoli 3y agoRegarding state: you can make thread safe transducers. The current SRFI 171 reference implementation is NOT thread safe. You can create a transducer and use it across different threads no problem. But you cannot start a transducer and use the returned reducer in different threads. It uses hidden mutable state.