Re: New egg: CHICKEN Transducers

[siiky]

> > (...) My reasoning is that (intuitively, without having looked at
> > an impl of either) type-fold is easier to implement than
> > type-transduce (...)
>
> Indeed, and this has been the reasoning in why I have left it for the 
> most part. An egg like this is nothing if it cannot be extended easily. 
> Noticing the distinction between implementing fold, collect, or some 
> entire abstraction that tries to do both was something I realized about 
> halfway through writing it (specifically, when I started adding fold / 
> collect procedures outside of the list variants).


I took some time yesterday to read and try to understand the impl 
(transduce, list-fold, list-collect, vector-fold, range-fold, ...) and 
it is indeed pretty uncomplicated. Amazing how something this simple is 
also this useful!

After reading the larger chunks of the impl, transduce is actually just 
a bit of boiler plate around the type-fold. I wonder if it would be 
worth using `type-transduce` instead, if there's also a `transduce*` (or 
something) that takes care of that boiler plate.


(define ((transduce* fold) xform collect) ...)

(define (type-fold ...) ...)
(define type-transduce (transduce* type-fold))


On one hand, it's a bit of typing saved for very little extra 
abstraction; on the other, it's a bit of abstraction for very little 
extra typing... ^^'

> I figured this criticism would come up. My thinking was that keeping 
> collectors prefixed with `collect-` helps autocomplete and gives you an 
> interesting symmetry:
>
>      (transduce list-fold (compose ...) collect-vector (list ...))
>
> Notice how you start with list- on the left and -vector on the right? 
> The transducer is in the middle and so you have list-transducer-vector 
> if you squint at it hard enough.

As long as there's a reason that makes sense I'm good. :)