Re: encapsulating directory operations

"Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message
news:100p1u4$3um4p$1@dont-email.me...

On 23.05.2025 07:20, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

If you have created a separate library, advertise it so that it
gets used, and if people are widely happy to have that library
suggest it for inclusion. Then committees might pick it up (or
not).

>
Or it might *not* be included in the language standard because
there's no need to do so.  If a library is popular, programmers
can just use it whether it's part of the standard library or not.
Plenty of popular libraries are not part of the C standard library --
and they don't need to be.

>
Yes, sure. - I thought this was what I wrote [with other words];
"might pick it up (or not)".
>
Honestly, I still don't understand Paul's fixation on the standards
track; i.e. beyond the good feeling one may have when contributing
something [potentially] useful. If it's a sophisticated library and
made available to the public that could be reward enough. (But who
am I to judge. To each his own.)

(sorry for the delay in replying)

And here's a chance to clear up another point.

It's none of those things.

It's the other way around.

I am religiously conforming to C90 and making all my tools, and my
OS, to C90.

I have been doing this for nearly 40 years.

Even when people complained about MSDOS being "different",
I didn't see any difference. I basically told them that they were
wrong. The implementation they were using was conformant
with the ANSI C draft - it's up to them to adjust, not MSDOS
nor anything else. If they write their software "properly", it will
work not just on MSDOS, but also on MVS.

At the time I didn't know why people were plastering "near"
and "far" keywords everywhere. In fact, I basically still don't.
I simply choose an appropriate memory model.

And I can remember talking to a long-term DOS programmer
who stated that you couldn't do xyz without doing a BIOS
call or directly manipulating the hardware. xyz might have
been getting a single character from the keyboard. And I said
no, you can get that with a standard read. You just need to
do this devioctl call first.

So that is the background. I just chose to follow C90,
religiously.

But the irony is I don't really have that as a religion - it
just appears that way.

When I understood the limits of C90, I had no religious
qualms about changing/forking C90. Only practical.

It has taken me nearly 40 years to find those limits.

And now I am hitting those limits.

E.g. I can't drive an EBCDIC X3.64 terminal unless C90
provides an ESC define.

And I can't do a "dir" either.

And nor can I do a non-blocking peep.

So now, belatedly, I am revisiting the C90 standard and
asking about its limits, and whether they should exist and
why they should exist.

All this time that I was "investigating", the ISO C and most
of the world had raced ahead, invalidating 36-bit machines,
invalidating MVS (as they always had anyway), etc.

I am now - belatedly - challenging that path of "development".

It doesn't really matter to me whether I actually succeed in
being more popular than the ISO strain of "development".

What matters to me is whether C90+ or C90-refined is
logical. And only if the C90 standard is sufficiently forked -
because it is logical to do so - can I say my ecosystem is
"completely portable".

That's what C90 is all about after all - making things as
completely portable as possible.

My #define ESCAPE 0x1b is not portable. It won't work
on EBCDIC. And crucially - it won't work on some other
theoretical character set - even if it includes an ESC.

So I have reached the limits of C90, and something has
to give. Or it is "time for something to give".

There are two ways to go.

I could say "ANSI x3.64 terminals cannot be supported
in a portable manner, and so I will use edlin for the rest
of my life".

Or I could say "change C90 so I can use microemacs".

I'm happy to change (or work on changing) the entire
mainframe ecosystem to switch from 3270 terminals
to EBCDIC ANSI terminals.

Actually succeeding in doing that (with or without
coercion), is a separate exercise. And I don't really
care if it happens or succeeds.

What I care about is that I made a logical attempt to
do so, which justifies my use of microemacs instead
of edlin.

At the end of the day, I'm trying to run microemacs,
while sticking to my principle of being standards-conforming.

I'm trying to run microemacs, not win Miss America.

I can demonstrate microemacs running on a mainframe.
So I know it is technically possible.

But it violates C90 and there is currently no C90+ I can
point to instead that my flavor of microemacs conforms to.

That's the issue.

If I had a C90+ I can start off by saying "the entire rest
of the world is wrong and I am right for following C90+
instead of C90 or a derivative".

To the person who said I should write to convey, not
convince - I'm not trying to convince anyone. I don't
care if no-one in the world moves to C90+ except me.
I'm just after the technical information required to
write C90+.

Making sure the identifier doesn't start with "E" is one
example of that. I wouldn't have thought of that myself.

I believe I will need some more identifiers for the
microemacs keystrokes too - like ctrl-x, ctrl-s to save.

The alternative (for me) is grim.

edlin

That's convey. Not convince.

BFN. Paul.