Iteration revisited
Daphne Preston-Kendal
(25 Oct 2021 06:30 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(25 Oct 2021 10:37 UTC)
|
Re: Iteration revisited
Daphne Preston-Kendal
(25 Oct 2021 11:27 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(25 Oct 2021 11:43 UTC)
|
Re: Iteration revisited
John Cowan
(25 Oct 2021 18:53 UTC)
|
Re: Iteration revisited
siiky
(25 Oct 2021 20:26 UTC)
|
Re: Iteration revisited
Amirouche BOUBEKKI
(26 Oct 2021 05:26 UTC)
|
Re: Iteration revisited Marc Feeley (26 Oct 2021 12:06 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(26 Oct 2021 12:17 UTC)
|
Re: Iteration revisited
Marc Feeley
(27 Oct 2021 14:13 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(27 Oct 2021 15:13 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(26 Oct 2021 07:14 UTC)
|
Re: Iteration revisited
John Cowan
(28 Oct 2021 00:48 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(28 Oct 2021 14:23 UTC)
|
Re: Iteration revisited
John Cowan
(28 Oct 2021 19:17 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(28 Oct 2021 19:42 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(29 Oct 2021 06:06 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(26 Oct 2021 07:27 UTC)
|
Re: Iteration revisited
John Cowan
(27 Oct 2021 15:35 UTC)
|
Re: Iteration revisited
John Cowan
(28 Oct 2021 00:31 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(28 Oct 2021 17:57 UTC)
|
Re: Iteration revisited
Amirouche BOUBEKKI
(25 Oct 2021 11:12 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(25 Oct 2021 11:28 UTC)
|
Re: Iteration revisited
John Cowan
(28 Oct 2021 00:13 UTC)
|
Re: Iteration revisited
Marc Nieper-Wißkirchen
(28 Oct 2021 17:38 UTC)
|
> On Oct 26, 2021, at 1:26 AM, Amirouche BOUBEKKI <xxxxxx@hyper.dev> wrote: > > Welcome to the conversation :) > >> > >> If I have a list of ports `l` and want to read the contents of all of >> > >> them, `(map (cute read-string #f <>) l)` is one "obvious" way to go. >> > >> Another probably better example is #f, although not related to >> > >> generators & whatnot, which is commonly used as the "null value". Except >> > >> when it is a valid input or output value. And that's why `maybe` from >> > >> SRFI 189 is useful. >> > >> siiky > > In another thread the Maybe approach was also mentioned. > > > The problem I have with eof-object in generator is that eof-object is not a disjoint type for a dijoint behavior such as described in null object pattern [0]. > In a way that is similar to JavaScript's `undefined` that shows up in code or errors, without giving information about what is the actual context or problem. A solution to this is to (conceptually) add a parameter to input procedures, i.e. read, read-char, read-string, etc which is the object to return upon reaching the end of file (or end of stream). The end of file can then be detected unambiguously by passing a unique object as this parameter and checking for eq? on the result of the input procedure. An optional parameter could be added to the input procedures but this would not be my choice. Instead the R7RS eof-object procedure should be turned into a parameter object (intitially bound to a “standard” end of file object) and the input procedures would be required to return the value bound to the eof-object parameter object upon reaching the end of file). I checked the R7RS and it seems this extension does not violate the current spec. Detecting the end of file unambiguously could then be done like this: (let ((my-eof (list 'unique))) (let ((data (parameterize ((eof-object my-eof)) (read port)))) (if (eq? data my-eof) ... ;; EOF reached ...))) ;; EOF not yet reached I suspect the R6RS authors had this in mind when the eof-object procedure was conceived. Marc