Welcome! Please see the About page for a little more info on how this works.

+8 votes
in Transducers by
edited by

Rich says in the History of Clojure:

I think transducers are a fundamental primitive that decouples critical logic from list/sequence processing and construction, and if I had Clojure to do all over I would put them at the bottom.

This fascinates me, and I am really curious what would transducers-first Clojure look like? I don't really expect Rich to answer here (I should have asked this at his HOPL talk...) but perhaps someone who is closer to core might have some insight.

I would love to see a Clojure where transducers are the default and easiest way to solve things, where all the tutorials and gists and example code everywhere around would be using them and a context (vector, lazy, first etc.) was only chosen at the edges. Currently it is easier (but perhaps not simpler) to write lazy code than transducing code.

I am wondering if transducers-first Clojure would address the above or would it mostly be about the plumbing behind a clojure.core similar to the current one.

For my personal case, I actively have to fight laziness - I don't think I encountered a single place in our codebase where it would be beneficial but as it's still the easiest way of writing clojure I have to put in extra effort to not accidentally venture over to lazy land and to spot these patterns in PRs of others.

I would love a clojure.core2 where transducers are the default, it's easy to write transducing code, potentially with less typing/ceremonies, the likes of comp and into [] etc. And stepping over to lazy land is always an opt-in thing, like the impure parts of clojure - stm, transients etc. I'm not entirely sure how a core library like that would look but it's something I'd love to try.

Moreover, there are some transducer-specific optimisations like https://github.com/cgrand/xforms#on-key-value-pairs that could be considered. And perhaps there could also be a way to use the multiple-coll arities of map as part of a transducer somehow.

There could also be more baked-in support for an xform arg in functions that currently take a coll to preprocess them, like run! and str/join - if you actively use transducers you start to notice things like 'hey, I don't even need a collection there' and start to look for different transducing contexts - so instead of (count (into [] xform input)) you'd go (x/count xform input)

1 Answer

0 votes
Thanks, that sure is an interesting project. It still appears to mimic Clojure's default lazy apis: https://github.com/pixie-lang/pixie/blob/master/pixie/stdlib.pxi#L152