Re: New egg: CHICKEN Transducers

[Peter Bex]

On Wed, Jan 04, 2023 at 06:48:56PM -0700, Jeremy Steward wrote:
> I've been somewhat bothered by the fragmentation in a certain aspect of
> Scheme / Lisp: notably that there isn't really something akin to Rust's
> Iterator trait in Scheme, and as a result working across various collections
> and data types is a pain.

Arguably that's a feature - in Scheme you'll always be sure of the
performance characteristics of the type you're working with, and you'll
always know what type you're working with.  Also, by not having generics
for collection types you avoid quite a performance overhead related to
dispatch. But I understand many people disagree that this is desirable.

> So I introduce to you - Transducers! These are very similar to Clojure's
> transducers, but add one more parameter: a fold procedure. I was unhappy
> with SRFI-158 (Generators & Accumulators) and also unhappy with SRFI-171
> (mostly because of how sparse the API is).

This looks quite nice and well done!

> And I've written a short blog post outlining some of my frustrations that
> led me to writing this egg:
> 
> <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/>

Excellent observations, especially regarding the fold argument inconsistency,
that's so cringeworthy it isn't even funny.  I thoroughly enjoyed reading
the post.  Even if it's critical of Scheme, it's done in a loving way,
as you mention ;)  I also agree with you that SRFI has probably had its
best time.

Besides just being "etched in stone", the SRFI process has been hijacked
by a small group of people and is producing SRFIs at breakneck speed with
perhaps not enough community input.  Usually by the time I learn about a
SRFI about a subject I find interesting, it's already finalized ;)
That makes SRFIs rather "take it or leave it".  And often they're not
especially ergonomic either.

> Happy to engage with the rest of the community on what the next priority for
> such a library should be. My hope is that this library helps us all move
> away from XXX-map and XXX-filter procedures for each individual type.

Well, like I said I kinda prefer having the type-specific procedures.
I rarely deal with situations where I don't know the type on which I'm
operating.  I usually treat generic code with suspicion, as it's not
going to be as fast as it could be, and higher-order code tends to be
more difficult to follow than necessary.

However, transducers offer one thing that the type-specific procedures
do not - pipelining without accumulating lots of intermediate results.
For me that's the killer feature of transducers.
 
> First things first: I'll probably keep trying to add more common data type
> support (SRFI 146 mappings and SRFI 69 hash-tables come to mind) as I can.
> Let me know if you find this useful!

Sounds good - the more native types are supported, the more useful a
"generic" transducer is.

Cheers,
Peter

signature.asc
Description: PGP signature