Additional procedures and extensions John Cowan (02 Apr 2021 04:09 UTC)
Re: Additional procedures and extensions Shiro Kawai (02 Apr 2021 06:37 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (02 Apr 2021 07:41 UTC)
Re: Additional procedures and extensions Wolfgang Corcoran-Mathe (02 Apr 2021 15:11 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (02 Apr 2021 15:39 UTC)
Re: Additional procedures and extensions Wolfgang Corcoran-Mathe (02 Apr 2021 17:58 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (02 Apr 2021 19:22 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (02 Apr 2021 20:43 UTC)
Re: Additional procedures and extensions John Cowan (03 Apr 2021 02:55 UTC)
Re: Additional procedures and extensions Wolfgang Corcoran-Mathe (03 Apr 2021 14:52 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (03 Apr 2021 15:11 UTC)
Re: Additional procedures and extensions Shiro Kawai (03 Apr 2021 18:50 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (04 Apr 2021 09:26 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (04 Apr 2021 11:04 UTC)
Re: Additional procedures and extensions Marc Nieper-Wißkirchen (04 Apr 2021 21:09 UTC)

Re: Additional procedures and extensions Wolfgang Corcoran-Mathe 02 Apr 2021 15:10 UTC

On 2021-04-02 00:09 -0400, John Cowan wrote:
> Wolfgang Corcoran-Mathe has proposed extending generators to return
> multiple values.  Since generators are just procedures, this is
> straightforward, but some convenience procedures would be helpful, and SRFI
> 221 provides a place to keep them.

The case that started me thinking on this was SRFI 224's
imapping->generator, which gives a generator for key/value tuples.
The natural way to implement this would be as an MV-generator.  The
case for other "dictionary" structures is analogous, so, on the whole,
I think that multiple-value generators definitely have their uses.

However, I agree with the points raised by Shiro and Marc.  You'll
need additional glue for converting these objects to SRFI 127 lseqs;
since easy compatibility with streams is a nice property of
generators, this is unpleasant.  The need to check the number of
values returned by an MV-generator is also rather ugly, and there's no
way to write a generator-coarity form to determine how many values to
expect.  So I'm unsure about extending SRFI 158 generators to provide
MV-generators.

Marc suggests a failure/success continuation-passing design; my current
habit is to translate all such design patterns into sum-type terms,
so here's one possible simple solution.  A multiple-value generator is
a generator procedure with a slightly different protocol: it returns a
Just of any number of values, or Nothing to indicate exhaustion.  This
protocol can be translated into the usual generator protocol in several
ways, the simplest being

    (define (maybe-generator->generator gen)
      (lambda ()
        (let ((m (gen)))
          (if (nothing? m) (eof-object) m))))

A slightly more baroque translation might take a MV-generator to a
list or vector generator.  In any case, this solution would be a
different SRFI, but I'm thinking that I'd prefer that over muddling
the current well-known generator protocol.

Best regards,

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"All this currying's just a phase, though it seldom hinders."
--Fritz Ruehr