"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.
The POSIX interface (readdir et al) happens to be the one I'm most
familiar with. In fact it's pretty much the only one I'm familiar with.
I have no comment on the others.
>
As I've said before, I don't think your idea of doing directory access
via fopen() is practical.
Sure. You explained that operations on directories are
different from operations on files, and it would nominally
be wrong to shoehorn directory access into a FILE
stream.
I didn't see anyone dispute that.
Although having said that - if FILE is a misnomer and really
means STREAM - perhaps directory access is also a stream,
and some streams require additional operations, e.g. streamMkdir().
Changing existing library implementations is not significantly easier
than changing existing compiler implementations. There are open source
implementations of both.
>
And here you have managed to tease out the unstated assumption.
>
I can and do use closed-source compilers like Microsoft C 6.0
and Visual Studio 2022.
>
They produce fantastic code.
>
But I bring my own library to the table - PDPCLIB. I basically
never use Microsoft's library. Or Watcom or anyone else.
>
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)
Apparently PDPCLIB is that library.
No. PDPCLIB is just one of many, many C90-compliant
libraries.
All your talk of defining
a new language based on C90 (whether you call it C90+, or C91,
or whatever), as far as I can tell, is not useful.
I apologize for not having the ability to express myself.
I can only see in hindsight what the issues are.
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.
C has *always* been designed to work with libraries in addition to
the standard library. POSIX is just one example. Win32 is another.
And there are countless other libraries, large and small. You don't
want to change the core language (Section 6 of the standard).
You don't need to change the standard library (Section 7); you can
Disconnect. I didn't say "need". The word is "want".
either use it as it's defined or ignore it. You can create and
document your own library that does whatever you want. It doesn't
have to be a "standard".
Disconnect. Not "have" - "want".
It's just a library. It may or may not
depend on features of the C90 standard library.
No. It IS C90+.
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.
Actually influencing ISO is a separate exercise.
It probably won't involve coercion.
But coercion wouldn't be required if the C90+ committee comes
up with something reasonable.
That's the goal. Something reasonable.
There's no portable way for the preprocessor to know whether the
target character set is ASCII, EBCDIC, or something else, but
can it be determined at compile time with a constant expression.
There is no need for portability. Every theoretical vendor
will implement it for their particular platform.
It is the standard itself that is portable. Not the implementation.
Note that this will likely fail if the target character set is not
based on either ASCII or EBCDIC. That's not likely to be relevant
in the real world, and apparently you've decided for some reason
not to care about the possibility.
I haven't really decided such a thing.
You can probably say that I have decided that future versions
of C will only work on character sets that include an ESC
character.
I (tentatively) don't want to be forever tied to the past. There
are some ancient platforms where you can't really implement
C at all, from what I saw of the description.
It's enough for me that the ASCII character set exists, but not
necessarily at those code points. There are EBCDIC equivalents
for every ASCII character. There are a couple of extra
printable EBCDIC characters. And I more-or-less wish to
ban their use. If such wording can be put into the standard
in a nice way. Like. "if you use the cent symbol, results are
undefined". Just warn people off. So sticklers for the standard -
like me - will not go anywhere near it.
I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.
>
But there's no such thing.
[...]
>
There is - I produce one myself (via emulation) - do you
want me to give you a link? Proven against real mainframe
hardware (despite the claims that my software will never
run on a real mainframe).
>
So there's one emulator that nobody other than you uses?
>
Ok, fine, whatever.
Even if there were 0 emulators, the argument would be
exactly the same as if 90% of the planet used it.
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).
That's a work in progress. And the progress of that is
completely irrelevant to the technical question - from my
point of view, anyway. That's exactly what argument
ad populum is all about.
BFN. Paul.
…