Re: encapsulating directory operations

"Paul Edwards" <mutazilah@gmail.com> writes:

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87h61ezf76.fsf@nosuchdomain.example.com...
>

It looks like it treats a directory as a file containing a
sequence of *lines*, each of which is a file name.  The problem
with that is that on some systems, file names can legally include
newline characters.  I don't suggest it's not a horrible idea to
take advantage of that, but it is something that would have to be
addressed in a language standard.

>
And - that's part of my question.
>
The language standard would need to say something along
the lines of "if any filenames contain a NL character, the
results are implementation-defined".

No, it would not.

I merely observed that one particular directory interface,
if I understand it correctly, would not correctly handle files
whose names contain a newline character.  If you want to define a
directory interface in your new language, I suggest that it should
not have this limitation.  If it doesn't have this limitation,
there's no need to make the results implementation-defined.

Accessing directories via fopen() would make it difficult but not
impossible to handle such file names correctly.  Perhaps that's one
reason why (as far as I know) no existing directory interfaces use
fopen().

[...]

Ditto MVS would be the reason why mkdir() can't be
implemented - and mentioned in the Rationale, not the Standard.

mkdir() could be defined in your standard library, but could always fail
on MVS.  (I'm assuming MVS doesn't support creating a directory.)
Or you could leave it out, making your language less useful on systems
that do support creating directories.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */