I wrote SRFI-171 for scheme. Ask me anything.
I have had many people tell me that the SRFI document [0] made transducers click for them, which is always a nice thing to hear.
I have had many people tell me that the SRFI document [0] made transducers click for them, which is always a nice thing to hear.
I believe I've submitted my own blog post on transducers in the past. See <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-tra...>
To bjoli: Have you seen my library? Any intentions to update the SRFI and incorporate more types?
I don't really understand what you mean by types (my implementation stays monomorphic so new types are easily introduced by TYPE-transduce) , but I have thought about generalising things like numerical ranges by having something like unfold-transduce.
This is more or less what I was wondering about. Numerics, ports, SRFI-41 streams, etc. There's a lot of stuff that isn't in e.g. r7rs-small but is more or less expected in most Scheme implementations.
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.
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.