Re: encapsulating directory operations

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

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87bjrkxonr.fsf@nosuchdomain.example.com...
Hi Keith.
>
I can now see a series of disconnects.
>
But hopefully now I can articulate the issue.
>

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

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a575zvmb.fsf@nosuchdomain.example.com...
Hi Keith.
>
First - thanks a lot of teasing out an unstated assumption.
>
I am often operating on a set of assumptions. But I don't
list them upfront because I don't actually know what
they are.
>

Are you sure - given the constraints - that a different interface
isn't appropriate?

>
I have not said or implied that the POSIX directory interface is the
only appropriate one.  It does have the considerable advantage that it
already exists.
>
My advice is to study and understand existing solutions before

inventing

your own.  I can't offer meaningful advice on what's appropriate for
your language.

>
I have now been given two pointers. Common Lisp,
and C++ 17. Do you have any comment based on
your knowledge of those?

>
You've been given at least three; you didn't mention POSIX.

>
No. That's not a language standard. Only in Common Lisp
and C++ 17, so far mentioned, has the actual language
standard - rightly or wrongly - another outstanding question -
was it right or not? - covered directories.

It doesn't matter to me whether a directory management interface is
part of a language standard or not.  I don't know why it matters
to you.  C didn't standardize opendir(), but POSIX did, so I use
opendir() on systems that support it.

[...]

If you're going to stick with existing C90 compilers, it seems
to me that all you need for your purposes is an add-on library.

>
Here's the first disconnect.
>
Yes - I already have an add-on library - that's the folder.c and
folder.h I referenced in the beginning. And unistd.h would be
another.
>
But neither of these are in C23. Nor were they in C90.
I want a slight variation to BOTH of those standards,
and for the next ISO standard - C30 or whatever -
to include that slight variation.
>
(I didn't previously state this, because I wasn't aware
of it, again)

I don't believe that you personally will have any influence over any
future C standard.  Your goals are too different from the goals of the
committee and those of the vast majority of people who care about C.

[...]

In this case, the plan is that my "add-on library", is so
small, and so useful, and hopefully so popular, that it
gets standardized into a theoretical C30, as well as
existing C90 libraries - including but not limited to
PDPCLIB - updated to include this new feature, that,
in hindsight, should have existed even in K&R C.

In my opinion that will never happen.

I have no problem with whatever functionality you want to provide in
your PDPCLIB, and I'm willing to discuss some of it in technical terms.

[...]

 It's just a library. It may or may not
depend on features of the C90 standard library.

>
No. It IS C90+.

I don't know what you mean by that.  If you mean that your PDPCLIB
library IS "C90+", that's fine; both are your invented terms.
But it's an odd choice of terminology.

The implementation of that library might have to be modified for
different target systems.

>
Of course. The language library standard simply says what is required.
>

I have: "support both ASCII and EBCDIC escape characters".  It's not
something I've ever needed to do, so I have not spent time or effort
deciding how to do it.

>
The C90 committee was forced to consider that. That's why
'A' to 'Z' are not guaranteed to be consecutive, but '0' to '9' are.
>
Without either ASCII or EBCDIC mentioned in the C90 standard.

>
I was specifically talking about the ESCAPE character, which the C90
committee ignored.

>
Sure. Sorry - loose language. They were forced - begrudingly
from what I think I remember I read - to consider the mainframe
implications. And most couldn't understand why the mainframe
was so complicated, with record formats etc.
>

Regardless, that's what I'm after - a decision on how to do it.
If you personally don't want to spend the time and effort and/or
make a decision, that's fine - I'm hoping someone in the group
will do that, and perhaps when they propose a solution you will
chime in and say "no, that's not a good idea for xyz reason".

>
In one of your library's headers:
>
extern const char ESCAPE;
>
In the corresponding *.c file:
>
const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>
Change the name if you prefer.

>
Disconnect. Not what I prefer. What the theoretical committee decides.
>
This is intended to be in the official ISO C standard for the next
1 million years.

That will not happen.

Actually influencing ISO is a separate exercise.

That will not happen either.

It probably won't involve coercion.
>
But coercion wouldn't be required if the C90+ committee comes
up with something reasonable.

That sounds like a threat.  If it is, I suggest you stick it where the
sun don't shine.  But as far as I know you have no ability to carry out
your threat, so it's more pathetically amusing that frightening.

[...]

You can probably say that I have decided that future versions
of C will only work on character sets that include an ESC
character.

That is not your decision to make.  (Nor is it mine.)

[...]

And if I am one day elected president of the USA, at the
same time as Chancellor of Germany, and a few other
places, you may well find 90% of the planet using it (or
at least, having it on their system).

See above regarding "where the sun don't shine".

[...]

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