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)
|
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