opendir / readdir / closedir reminds me to old DOS ages. What exactly is the benefit of that transactional (?) model? Why not use simply traverse-dir? It in the the traverse-wordlist pattern, already known in the standard.

Yes, the traverse-dir approach also has the advantage that you could pass the matching information, and either implement it on POSIX with fnmatch, or on DOS/Windows with the mask passed to FindFirstFile.

traverse-dir ( ix diraddr u1 patternaddr u2 xt -- kx ) with xt taking ( ix fileaddr u -- jx )

One question for mkdir that automatically creates ancestors — should it remove the directories created on the previous steps if it fails on some step?

My old LAY-PATH implementation does not remove intermediate steps on fail.

In any case, the operation is not atomic. But this should be mentioned.

Also, it seems to me that developing such proposals in GitHub (or perhaps in GitHub/ForthHub) is far more convenient than here. Version control gives too much to don't use it.

@mtrute, @BernyPaysan: traverse-dir would certainly be comfortable if you want to iterate a single directory. But having open/read/close one can easily compare multiple directories and it would be trivial to implement traverse-dir.

@ruv: I agree with you, that a version control would add quite some convenience. However normally proposals are developed in smaller groups and only presented to the public once they are pretty solid. At the standards meeting the committee decided to allow for experimental proposals, and Ullrich Hoffmann and me wanted to take it one step further and publish a very drafty version to collect some early feedback. Additionally let me point out that forth-standard.org tries to centralize the committees actions. That being said, I'll look into implementing some versioning features.

Thanks for pointing out the problems with a failing mkdir for parents!

@GeraldWodni To compare two directories, you either need to sort both (the answers of read-dir can be in any order the OS chooses; usually, the file names are returned in the order they are stored in the directory, which is very implementation specific), or take the filenames of one one-by-one and do a FILE-STATUS check in the other, and repeat the other way round, so no, read-dir doesn't help much here.

The TRAVERSE-DIR documentation needs some more words, e.g. about the lifetime of the provided buffer for xt: This is a one-shot buffer, and the data there lives only for one call of xt. On the other hand, it is always as large as needed, unlike the READ-DIR output, which can indicate that the result didn't fit.

That alone makes TRAVERSE-DIR much easier to use and harder to implement.

Yes, TRAVERSE-DIR, and JOIN-PATH need to specify where the output string is and how long it lives. Also, the buffer handling of READ-DIR makes it hard to use properly. Better make an interface like

read-dir ( dir-id -- c-addr u ior )

where the resulting string lives until the next invocation of read-dir (for the same dir-id?), and c-addr u is 0 0 if there is no entry left.

Should we not use the name CREATE-DIR rather than MAKE-DIR in sympathy with the file words?

As I have been ask where the current implementation lives (not finished), it is on github GeraldWodni/directories

What was a rationale to change names from

path-basename, path-dirname, etc

to

basename-path, dirname-path, etc

?

It seems to me, these words are similar to file-status, file-position, etc., so the former names are better.

normalize-path is OK since it's in the form "{verb}-{noun}" and it modifies the input string.

The committee asks the author to please work the comments into your proposal and update it. Also please provide a full reference implementation.