> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, September 04, 2019 6:46 AM
>
>> One unanswered question from a few weeks ago was if we should
>> provide a facility on top of open/read/close-directory that deals
>> with very large directories more gracefully than directory-files,
>> which just returns a list.  If so, lots of good examples were
>> referred to, and this snippet might be the best point we got to
>> while discussing it:
>
> In the current draft, there's a "read-directory" procedure which
> does this really nicely.

It's a wrapper of POSIX readdir, which with the one for opendir per
your observations of their use in the field never returns "." and
"..", and has an optional argument if you want any other dot files.

> It easily supports generator-style and fold-style helper procedures,
> as well as directory ports (i.e. open-directory returns a special
> kind of port as in Gambit).

We decided that ports are too low level and implementation dependent
for this SRFI, but I for example use a slightly modified for
dot-files? version of Chibi's directory-fold to supply
directory-files.  However we decided including a directory-fold was
beyond the remit of this SRFI, which in a later email you made today
you agree with:

> To answer your inquiry about including folds and such in the base
> SRFI, I vote to leave them for higher-level libraries such as glob
> (I think I changed my mind on this at some point). But if others
> really want to include a directory fold in the base SRFI, I'm still
> not against it.

But we're working on a generator to add to the SRFI.

- Harold