Quick question about SRFI-170 directory-files hga@xxxxxx (29 Jul 2019 15:46 UTC)
(missing)
(missing)
Re: Quick question about SRFI-170 directory-files hga@xxxxxx (29 Jul 2019 17:08 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 17:42 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 17:51 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 18:03 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 18:15 UTC)
Put directory-fold in the SRFI? hga@xxxxxx (29 Jul 2019 18:45 UTC)
Re: Put directory-fold in the SRFI? John Cowan (29 Jul 2019 19:38 UTC)
Re: Quick question about SRFI-170 directory-files John Cowan (29 Jul 2019 20:27 UTC)
Re: Quick question about SRFI-170 directory-files Marc Feeley (29 Jul 2019 18:28 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 18:31 UTC)
Re: Quick question about SRFI-170 directory-files Marc Feeley (29 Jul 2019 18:46 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 18:57 UTC)
Re: Quick question about SRFI-170 directory-files Marc Feeley (29 Jul 2019 19:04 UTC)
Re: Quick question about SRFI-170 directory-files hga@xxxxxx (29 Jul 2019 18:32 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 18:51 UTC)
Re: Quick question about SRFI-170 directory-files hga@xxxxxx (29 Jul 2019 19:16 UTC)
Re: Quick question about SRFI-170 directory-files John Cowan (30 Jul 2019 18:52 UTC)
Re: Quick question about SRFI-170 directory-files hga@xxxxxx (30 Jul 2019 19:58 UTC)
Re: Quick question about SRFI-170 directory-files John Cowan (30 Jul 2019 20:44 UTC)
(missing)
Re: Outstanding issue: directory-files in the context of huge directories Marc Feeley (04 Sep 2019 12:32 UTC)
make-directory-files-generator hga@xxxxxx (06 Sep 2019 16:21 UTC)
Re: make-directory-files-generator hga@xxxxxx (06 Sep 2019 17:26 UTC)
(missing)
Re: make-directory-files-generator hga@xxxxxx (06 Sep 2019 21:56 UTC)
Re: Quick question about SRFI-170 directory-files Lassi Kortela (29 Jul 2019 18:06 UTC)

Re: Outstanding issue: directory-files in the context of huge directories Marc Feeley 04 Sep 2019 12:31 UTC

> On Sep 4, 2019, at 8:20 AM, John Cowan <xxxxxx@ccil.org> wrote:
>
> I missed sending this to SRFI 170.
>
> ---------- Forwarded message ---------
> From: John Cowan <xxxxxx@ccil.org>
> Date: Tue, Sep 3, 2019 at 5:56 PM
> Subject: Re: Outstanding issue: directory-files in the context of huge directories
> To: <xxxxxx@ancell-ent.com>
>
>
> So here's the generator:
>
> (define make-directory-files-generator
>   (case-lambda
>     ((dir dot-files?) (make-directory-files-generator* dir dot-files?))
>     ((dir) (make-directory-files-generator* dir #f))))
>
> (define (make-directory-files-generator* dir dot-files?)
>   (let ((dir-obj (open-directory dir dot-files?))
>           (eof (eof-object)))
>     (lambda ()
>       (let ((f (read-directory dir-obj)))
>         (if (eq? f eof) (close-directory dir-obj))
>         f))))
>
>
> I haven't actually tested this, but it's at least conceptually correct.
>
> Although this overlaps the utility of directory-files, I want to preserve the latter (and Harold agrees).  When WG1 voted on the issue, directory-files was the highest-ranking result in the STV voting; however, it did not command a majority of the votes cast, which is why it does not appear in R7RS-small.
>

Unfortunately, with this “generators” abstraction, there is no way to put a timeout on generating the next value.

In Gambit all ports, including directory ports but also pipes and network listen sockets, have a timeout setting so that it is possible to indicate that the caller isn’t willing to block for more than a given amount of time, something that is essential for real time systems.  In other words, ports are a more powerful abstraction than generators (thunks).  It reminds me of the problem with the use of procedures to represent continuations created by call/cc, which then can’t be used for more advanced continuation operations (such as walking the stack, knowing who the caller is, accessing the continuation’s environment, etc).

Marc