> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, December 11, 2019 4:58 AM
>
>>> I like directory-files because it's the dead simple API: directory
>>> path in, list of entries out (dot-files optional).  It is of course
>>> redundant with the generator interface, and would not be the end of
>>> the world to omit.
>
> We all like it, but it's up for debate where it should go. IMHO
> higher-level niceties such as glob, directory-files and various
> shell-like procedures (pwd/cd/ls/cp/mv) would go better in a separate
> SRFI or other library. Then the current SRFI would have the essential
> stuff that's hard to implement due to being OS/FFI-dependent. Stuff
> that's simple to implement using portable building blocks from this
> SRFI I would classify as higher-level abstractions.

I can see the argument for that.  On the other hand, with the
exception of call-with-temporary-filename, I think the "simple to
implement using portable building blocks" procedures already
specified and implemented in this SRFI like the other temporary
file procedures are just that, an implementor of the SRFI should
be able to take the simple supplied example code and with little or
no modification add it to their implementation.

That does imply my polishing that code, and having it reviewed by
people who's Scheme experience isn't mostly decades old.  Which
would be a good idea anyway before finalizing this SRFI.

> [ We agree close-directory is required, and implementation details
>   for read-directory, including WinAPI. ]
>
>> (define (directory-fold dir kons knil . o)
>>    (let-optionals o ((dot-files? #f))
>>      (let ((do (open-directory dir dot-files?)))
>>        (let lp ((res knil))
>>          (let ((file (read-directory do)))
>>            (if (not (eof-object? file))
>>                (lp (kons file res))
>>                (begin (close-directory do) res)))))))
>>
>> Which is called with (directory-fold dir cons '() dot-files?) [to
>> implement directory-files]. I have no informed opinion on whether it
>> should be added to the API.
>
> Since you gave very good arguments for exposing an open/read/close API,
> a fold would just be this thin wrapper around it. IMHO we don't need to
> have both APIs. (directory-fold ...) looks like it would be neat to
> implement in terms of a general (resource-fold open read close ...).

Another argument against supplying the ease of use procedures in this
SRFI, just where do we draw the lines?

- Harold