4 ms·
> They are not similar at all, except that they might overlap. (Well, which is it?) Perhaps I was misled by the intro to the article, that wished for somethin
by tonyg 2y ago
> They are not similar at all, except that they might overlap.
(Well, which is it?)
Perhaps I was misled by the intro to the article, that wished for something like Rust's iterators: generic data-source-neutral map/filter/zip/etc utilities, static dispatch, extensible. Srfi-42, Racket's for/* system, and your goof-loop all seem to fit the bill. Obviously the article ended up at a dynamically dispatched system, like -171, but to start with it didn't seem like it had to have headed in that direction.
> Srfi-42 is couple of loop macros.
This is decidedly ungenerous, especially given its historical relationship to Barzilay's work and descendants.
- bjoli 2y ago> (Well, which is it?) The more I have though about these things, the less I see them as something similar. They overlap because they are sold as an alternative to map, filter etc. I think that is a pretty non-exciting use case that is better served by proper looping facilities. What is interesting about transducers is that they can be the basis for a generic protocol for transformations. You can make a transducer and use it on a list, pass it to a port constructor to have it preprocess everything read from the port, pass it to an asynchronous channel, make it into a generator. That is something not served by looping macros. > This is decidedly ungenerous I did not mean to disparage srfi-42. It _is_ a couple of looping macros (that set the bar for descendants), which I mean is what sets it apart from the exciting use cases of transducers. I think a language should have both. Racket took srfi-42 and showed that it doesn't have to use mutation. The reference implementation of SRFI-42 uses set! quite a lot which tanks performance in many schemes.