Rewriting it to not require a port is simple, and a separate generator-transduce could simply be added as an alias to that procedure arity. Good idea.

Generators can however be supported without any fuzz, and I don't think I have seen any other kind of generators used (returning any other thing than #!eof when they're done.

With the amount of generator procedures added in newer srfis it can prove useful.

I will add it.

--
  Linus Björnstam

On Mon, 7 Oct 2019, at 17:05, Lassi Kortela wrote:
> The port-transduce procedure doesn't seem to have anything port-specific
> in the interface or implementation, though it is clearly useful with
> ports. The reader can be any closure that yields some objects and then
> #!eof.
>
> The reader abstraction is almost identical to the generator abstraction
> in SRFI 158 (Generators and Accumulators). The only difference is that
> the reader takes a port argument whereas a generator takes no arguments.
>
> Since current-input-port can be locally bound with 'parameterize' to
> change which port one is reading from, would it make sense to turn this
> into a more generic generator procedure? The R7RS standard read,
> read-char, read-line and read-u8 procedures are already usable as
> generators.
>