Re: New egg: CHICKEN Transducers

[Tomas Hlavaty]

Hi Jeremy,

thank you for interesting reading.

On Wed 04 Jan 2023 at 18:48, Jeremy Steward <jeremy@thatgeoguy.ca> wrote:
> <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/>

   My main problem with generators and accumulators is that they
   basically replace all our existing data types with a new type
   (generators) that can then be mapped / filtered over in a unified
   way. After one is done with gmap / gfilter / etc. they can then
   convert this generator back into some kind of type using an
   accumulator or one of the built in generator->type procedures. This
   solves a problem of abstraction by routing around it. Rather than
   worry about what operations are defined on a type, we instead just
   create a type that has all operations work on it.

What are the procedures reduced? and unwrap in your example?
Don't they point to similar issue with transducers?

   This kind of approach is a good first abstraction, but fails because
   it is generally impossible to make this fast. It also doesn’t solve
   the fact that we have type->list and list->type proliferation. If
   anything, it makes it worse because most libraries are not
   generator-aware, and writing generators correctly can be
   tricky. That’s not to say writing any code cannot be tricky, but the
   obvious ways to write a generator are often using
   make-coroutine-generator which uses call/cc4 and as a result is
   pretty slow on most Schemes.

It seem that the problem is with the way people write generators in scheme.
Not that generators are "generally impossible to make fast".

Regards,

Tomas