Awesomesauce, thanks for the egg and the post! This is a smnall-ish pain
point of mine too. I'm still processing the post as well, but I can tell
I'll start using this frequently!
First a couple of typos: In footnote 4 it should be `call/cc` and not
`call-cc`? And "its not the Scheme I reach for" :p
About question (1) of "Some open problems ...": IMO (transduce type-fold
...) is a good compromise, and it seems better to me than
(type-transduce ...) though it means a tiny bit more typing. My
reasoning is that (intuitively, without having looked at an impl of
either) type-fold is easier to implement than type-transduce, and thus
it should also be easier for someone to extend the transducers egg with
their own fold+collect rather than transduce+collect. An usecase of
extending the transducers egg is e.g. if I have an egg where I define a
data structure foo and would like users of my egg to use transducers on
(with?) foo, but without having to change the transducers egg itself.
Regarding (4) and strings: if we survived without transducers until now,
I think can survive until transducers for strings until C6 too and use
string->list+list-fold :) (I'm assuming UTF-8 will only become core in
C6, maybe I'm wrong)
Small nitpick comment: I think it makes more sense to have either
type-fold+type-collect or fold-type+collect-type. It's more common in
Scheme to name type-operation so I'd give preference to that, but the
other is more natural and equally good IMO.
Thanks,
siiky
