> A quick reply to a couple of points; as of yet I have no strong
> feelings or thoughts about the other points you're bringing up:

Thanks!

> You're welcome, and we're going to be living with this SRFI for a long
> time even as it probably gets updated and superseded, we need to get
> it as right as is reasonable.  And I have that tendency too, which
> implementing another version of it reinforces.

Great, I also love working with nitpickers :) One of my most frequent
laments in software projects is not _enough_ nitpicking.

> But one reason this comes up is that the raw POSIX open/read/closedir
> syscalls *do* return dot and dot-dot, and I just made a LGTM (I hope)
> change to the SRFI to have those functions be simple wrappers that
> don't filter them out.  Lots of other interfaces keep them by default,
> like Emacs dired mode.

Simple wrappers are a noble goal, but this is an exception. I've been
dealing with this problem for a decade in countless jobs and languages
and including dot and dot-dot in the listing just slips in bugs. I view
them as similar to the EINTR thing - there's just no use case for manual
dot-dot handling or EINTR and they lead to bugs.

Dired is not a good point of comparison here since it's an interactive
directory lister and gives much more info than just names. In shell, "ls
-al" (small letter "a" to include dot and dot-dot) is useful because you
can show the owner and permissions of the current and parent directory.
But that info comes from doing stat(".") and stat(".."). Since you know
that "." and ".." always exist, you can just stat() them manually for
the few applications where they are needed.

>> But interactive use is so different that I wouldn't make that a priority
>> for a general-purpose OS SRFI like this.
>
> On the other hand, we want to make using the SRFI from the REPL as
> convenient as possible.

I think we're hitting the same problem that has plagued the Unix command
line since its inception: interactive use is fundamentally different
from script use. For example, "rename" overwriting the target file is
find in a script, but generally not on the command line. Similarly, for
interactive use, a (ls) procedure to list the current directory would be
simpler.

It might make sense to distribute a semi-standard alias/wrapper package
for interactive use, with abbreviations, confirmation prompts and nice
defaults. It could be quite simple.

> Since [dir [dotfiles?]] is dead simple, and we want to keep the SRFI
> conforming to scsh as much as is reasonable, I'd like to keep the current
> signature

It's not dead simple when you ask "why filter out dotfiles specifically
and not something else?"

For interactive use, where it makes sense for 'ls', I'd go with separate
aliases as above.

> modulo your points about it returning "too many" directory
> entries.  Which can happen, people have abused UNIX file systems a lot,
> requiring it to be very good at handling a ridiculous number of files in
> any directory.  Usenet back in the day was the canonical example, typical
> implementations stored the complete set of a topic's currently retained
> postings in a single directory, one file per posting.

That's a very good point. Maildir <https://cr.yp.to/proto/maildir.html>
may give the same problem nowadays. Also people still mount NFS/SMB
shares and those are rife with all kinds of problems like network
congestion, server downtime etc. So it's nice to be able to get only
part of the listing and stop as soon as you have what you need.