On 2021-04-02 17:38 +0200, Marc Nieper-Wißkirchen wrote:
> Am Fr., 2. Apr. 2021 um 17:11 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
> > However, I agree with the points raised by Shiro and Marc.  You'll
> > need additional glue for converting these objects to SRFI 127 lseqs;
>
> Streams are, in principle, well-adapted to multiple values. It's just that
> multiple values are not exposed by the SRFI 41 API.

I'm not sure I understand what you mean by that last sentence.

My point was mainly about odd streams, which are closely related to
generators.  The generator->lseq of SRFI 127 wouldn't work with
multiple-value generators without some glue; if this SRFI is going
to add MV-generators, I'd like it to also include a conversion to
lseqs for them.

> > 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
>
> This data-directed approach is IMO not the "right" way to do it in a
> functional programming language with tail-calls unless you need to store
> the Maybe value. Moreover, wrapping everything in Maybe's means extra
> allocations on the heap.

"Yeah, well, that's just like your opinion, man."  I don't see any
compelling reason to choose continuations over data.  As for the
extra allocations, I can't imagine that the expense will ever be
significant.

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

"Conventional programming is precise only about 'how',
not about 'what'." --Conal Elliott