> (Added the list as CC:) Thanks for keeping us in the loop (and sorry for being the resident nitpicker). >> It's signature is: >> >>> (directory-files/[dir dotfiles?]/) >> >> Seems to me that /dir/ and /dotfiles?/ should be independent >> optional variables, if you specify a directory, you shouldn't >> have to also specify if you want to see the dot files. A 'dotfiles?' argument is an interesting idea. I would personally leave it out, but it's not a clear call. - I would always leave out dot and dot-dot from the results (the two directory entries that reference the current directory and the parent directory, respectively). Those are not useful for anything - you know that they always exist even without listing them. And to get info about them, you need to call stat() anyway - readdir() can't be relied to return any useful info about them. Also Python's os.listdir() has left them out for probably more than a decade and it hasn't caused problems. - For other dotfiles, I can see that it can be useful to leave them out. However, sometimes you want them. And there are many other kinds of files that are useful to leave out also - such as editor backup files, binary files, empty files, non-regular files, etc. I would perhaps leave dotfile to higher-level frameworks like 'glob'. - A more general alternative would be a user-supplied filter procedure. But that again gets into the territory of higher-level frameworks IMHO. - Common Lisp used to have a 'with-directory-iterator' function in some third-party library. So instead of returning a list of names, it returned an iterable. For filtering, this could be the best option. A directory _can_ in principle have 10k files or even more. - Go's Readdir function takes an integer argument that gives the maximum number of names to return. I think that's great, and it might make sense for Scheme too. Personally I would rather have an optional max argument than a dotfiles? argument, but this is not as black-and-white to me as the exec-path-list thing - I can easily understand why you'd want a 'dotfiles?'. - Continuing with the Go community, I tried to suggest that their "get filename extension" function should have a special case for dotfiles, so it doesn't think the whole filename is the extension. To my surprise, they responded that they don't really believe in dotfiles and think those are a hack. They didn't implement my proposal despite the fact dotfile-sensitive behavior exists in Python's path extension function. > Actually was thinking /[dir [dotfiles?]]/, not thinking that listing the > current working directory is going to be super common, and a user can > just put (working-directory) for /dir/ since we helpfully supply it. > But I have no strong feelings against discriminating on type, besides it > making the implementation significantly more complicated, since /[foo > [bar]]/ is dead simple with Chibi Scheme's let-optionals ... which > originally came from scsh.... If listing the current directory by default is from scsh, it's probably for interactive use. When writing a script, I agree that it's not really a useful shortcut, and can confuse more than help. But interactive use is so different that I wouldn't make that a priority for a general-purpose OS SRFI like this.
