In grabbing your changes, I got your first cut on the per-thread vs. per process optional features.  I believe the addition of "may use" in front of the POSIX call is gratuitous.  That feature is documentation first and foremost to tell a user where to start looking to find out the procedures are all about, we don't assume they're well versed in POSIX.  And for the Schemer who knows both, it's an assurance he's in the right ballpark in trying to understand a procedure.   For the implementor, merely a suggestion for the most obvious function to use.

It's expected implementors will do as they see fit: like the use of [...]at functions to handle long filenames a bit at a time, discussed long ago with a conclusion that the SRFI would not provide such implementation hints, and was mentioned recently as being used for this purpose.  Something that would ideally be added to my Chibi Scheme reference implementation should it elevated to production quality, but for now best omitted to make it simple and straightforward.

- Harold

----- Original message -----
From: John Cowan <xxxxxx@ccil.org>
Date: Friday, April 24, 2020 2:22 PM

I agree that having a default here is inconsistent and not all that useful, and I have removed the optional nature of the *dir* argument from `directory-files`.

On Fri, Apr 24, 2020 at 12:34 PM <xxxxxx@ancell-ent.com> wrote:

An effectively fresh look at the text is very useful, or, why did we not notice this before...?

directory-files makes the dir argument optional, defaulting to the current working directory (whatever that'll end up being), while make-directory-files-generator and open-directory require it:

(directory-files [dir [dotfiles?]])    →    string list       (procedure) 
(make-directory-files-generator dir [dotfiles?])    →    generator       (procedure)
(open-directory dir [dot-files?])    →    directory-object       (procedure)       POSIX opendir()

I can't recall, nor could I find in a quick search of the list archives, any reason they should be different.

Thinking more about this, the directory-files optional argument nesting is not good, why should I have to specify a directory if I only want the complete list of files in my current directory (minus "." and ".." of course)?  It would make more sense to either require the directory as the generator and wrapper procedures do, or type dispatch on the arguments.  Up to now, if I remember correctly we've avoided the latter, and I'd like to continue that, this SRFI is complex enough as it is.

The major argument I can think of for allowing a default dir would seem to come from the heritage of scsh, "scheme shell", which is much less valid for this SRFI.

(Note, we previously discussed at length and agreed upon having all 3, the low level follows the simple wrapper philosophy of the SRFI, and is needed when you want to explicitly close the directory-object after a partial look at a directory, directory-files is dead simple and satisfies 80+% of the use cases without blowing up your heap, and generators are both cool, and very useful for when perusing a file system that's used for something like the historical examples of document databases.  And the latter two are simple enough Scheme code, an implementor should be able to cut and paste them from my example Chibi Scheme implementation modulo the optional argument handling.) 

- Harold