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