3 ms·

Is there a gain of clojure transducers to js style iterators? - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator https:

Is there a gain of clojure transducers to js style iterators? - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator/map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... both solve the copying problem, and not relying on concrete types

bjoli 5mo ago
They compose. And can be passed around and be completely oblivious to how they will be reduced. With conj or sum or whatever they want. And you can extend them at any point at any end. They are like map, filter and friends, but they compose. I think of iterators as an iterator protocol and transducers as a streaming protocol. An iterator just describes how to iterate over a collection. Transducers are transformations that can be plugged into any point where data goes in one direction.
- css_apologist 5mo ago
  js iterators work over lazy streams
  - bjoli 5mo ago
    As I said, it is a protocol for iteration or data access. You cant take an iterator and hand it as a filter to a file reader. If I make a rot13 transducer I can hand it to a transduce function that transforms a collection. I can give it to a file reader as a transformer on any char. Transducers are way to express transformations.
    - deleted 5mo ago
      [deleted]
joe-user 5mo ago
I think the misunderstanding is about iterators "not relying on concrete types". Rather, iterators are the concrete type. Consider the example transformation from the transducers page: (def xf (comp (filter odd?) (map inc) (take 5))) You'll see there's no notion of a concrete type that the transformation operates on. It can work with vectors, seqs, core.async channels, etc. Now consider how that could be written in JavaScript such that it works on arrays, sets, generators, iterators, etc. without having to first convert to another type (such as an iterator). That is what's meant about transducers not being tied to a concrete type.
- css_apologist 5mo ago
  i see so it's more than all tranducable types implement a common interface? or the tranduceable operators depend on a small subset of generic functions?

bjoli 5mo ago

They compose. And can be passed around and be completely oblivious to how they will be reduced. With conj or sum or whatever they want. And you can extend them at any point at any end. They are like map, filter and friends, but they compose. I think of iterators as an iterator protocol and transducers as a streaming protocol. An iterator just describes how to iterate over a collection. Transducers are transformations that can be plugged into any point where data goes in one direction.

css_apologist 5mo ago
js iterators work over lazy streams
- bjoli 5mo ago
  As I said, it is a protocol for iteration or data access. You cant take an iterator and hand it as a filter to a file reader. If I make a rot13 transducer I can hand it to a transduce function that transforms a collection. I can give it to a file reader as a transformer on any char. Transducers are way to express transformations.
  - deleted 5mo ago
    [deleted]

joe-user 5mo ago

I think the misunderstanding is about iterators "not relying on concrete types". Rather, iterators are the concrete type. Consider the example transformation from the transducers page: (def xf (comp (filter odd?) (map inc) (take 5))) You'll see there's no notion of a concrete type that the transformation operates on. It can work with vectors, seqs, core.async channels, etc. Now consider how that could be written in JavaScript such that it works on arrays, sets, generators, iterators, etc. without having to first convert to another type (such as an iterator). That is what's meant about transducers not being tied to a concrete type.

css_apologist 5mo ago
i see so it's more than all tranducable types implement a common interface? or the tranduceable operators depend on a small subset of generic functions?