Re: encapsulating directory operations

"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.

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.

[...]

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.
Apparently PDPCLIB is that library.  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.

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
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".  It's just a library.  It may or may not
depend on features of the C90 standard library.

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

[...]

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.

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.

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.
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 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.

[...]

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