Re: encapsulating directory operations

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

Do not mistake my idle comment for an endorsement.

>
I don't need an official endorsement. What I need to know
is that you can't think of any philosophical reason that the
C90 committee shouldn't have done that - had they chosen
to do so.

>
No, I don't believe you need to know that.  I consider the question of
what the C90 committee could theoretically have done in some alternate
timeline irrelevant.

You're reading too much into my idle use of "C90 committee".

I'm not talking about what the personalities were or anything
like that. I'm trying to "set the stage". ie there were existing
machines - including 36-bit machines - that needed to be
supported. They can't just be dismissed as "museum junk"
so that you don't need to go through the intellectual exercise
of how best to support a 36-bit machine.

"My C90+ committee" (a theoretical construct), needs to
support 36-bit machines. They cannot be imagined out of
existence. Nor can mainframes. Nor can MSDOS, so the
committee may start agonizing over whether the add the
"far" and "near" keyword in due course, but that process
hasn't started yet.

Or my committee where I can't get any compiler vendor
at all (except for the compilers I control) to add such a thing.

>
You don't have a committee.
>
Still, you claim to be creating a new language that happens to be based
on C90.  Are you adding a new constraint that any differences between
C90 and your language cannot require compiler changes?
>
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.

And I am happy to go to any platform (OS, not compiler),
and bring my own C library (and modify it as required),
and use whatever C compiler I happen to find on that
platform.

This has been done over 30 years, and I have refused to
put anything non-C90 into my library. Which upset some
people.

Only now - with the platforms I have immediate interest
in (mainframes, MSDOS, Amiga, Linux etc) covered to
my satisfaction by C90 - which for example included
changing a couple of paradigms that the IBM mainframe
library used - which also upset a lot of people - I am
considering putting non-C90 stuff into PDPCLIB.

Note that none of this stuff is being done to deliberately
upset people. I just don't want to be constrained by
decisions IBM made at the time - oh yeah - another
unstated assumption - nor do I want to be constrained
by existing code.

Existing code, existing libraries, existing standards, are
all important guides, but not hard constraints.

I have "no" interest in "fixing" bitwise precedents in
C90, for example. I reserve the right to change my
mind about that in 20 years from now or whatever
though.

But right at the moment, I am interested in issues that
came up when I assembled an entire ecosystem (OS
and toolchain), as well as supporting the existing
mentioned OSes.

I can't practically change Visual Studio, but even then,
I would be open to negotiation, if someone were to
say "look, all the extant compilers support xyz, and
if you zap offset 156383 of cl.exe in Visual Studio,
it will be brought into line with all the other compilers,
and xyz is the way forward", then I would indeed
consider compiler changes.

But I seriously doubt that xyz even exists, much less
that it could be "fixed" with a 1-byte zap.

So while I don't want to say "I refuse to change
existing compilers", in practice, that is the case.

What I am more likely to say is "I don't want to support
Microsoft C 5.1, even though it is freely available (as
part of the MSDOS 4.0 distribution - you need to use
Microsoft C 6.0, which isn't, or switch out to Watcom
or something".

Microsoft C 6.0 can compile PDOS and PDPCLIB as-is,
5.1 can't.

I'm not totally ruling out changing PDOS and PDPCLIB though.
I could potentially change them to support not just Microsoft
C 5.1 but also SubC, or an improved SubC.

So yeah - I'm happy to change the extant code that I care
about (which, unusually, is not a lot - I only care about my
toolchain/ecosystem - which is all C90-compliant).

Even though I only care about that, it so happens that
other people's C90-compliant code should work fine on
the ecosystem that I provide. But maybe one day in the
future I will invalidate all bitwise code that doesn't use
brackets appropriately. Or the other way around. But
right at the moment, I haven't diverged one iota from
C90.

Also right at the moment, PDOS-generic has a very
crude and awful directory listing mechanism, and I'm
looking to fix that, which is why I'm here to decide
my next move, as there are multiple ways to go.

In the past, I have just used MSDOS as a guide, as it
is a simple system, so they've probably solved the
problem already for all systems, including small systems.
But the DTA structure they use seems very inappropriate
to me. And so first I am asking about the theoretical
underpinnings of directories. I doubt that after hearing
about the theory, the conclusion will be "so DTA is
definitely the way to go!". But I don't want to prejudge
that.

With this new information that you're unwilling to do anything that
requires compiler changes, it seems to me that you can achieve your
goals by taking an existing conforming C90 implementation and adding
some library code (headers and implementation).

Yes.

One more time, C90 itself will not change.  You're free to define your
own language/library/whatever based on C90, but it will not be C90.

Yes, I acknowledge that long ago.

I have stayed in port for the last nearly 40 years.
>

In practice, if I need an escape character, I use '\x1b'.  I've never
needed to use an EBCDIC escape character.  If I did, I'd use '\x27'.
If I needed to support both ASCII and EBCDIC escape characters,
I'd find a way to do that.

>
Thats's my question - "find a way". Specifically - what way?
>

None of this requires language or standard
library support.

>
It is unclear to me why you are saying that. First of all, you
haven't specified what "find a way" is.

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

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

That's what I'm here for/looking for - discussion. A similar but
not identical discussion that the C90 committee would have had.

A very different environment. No time constraint. Benefit
of hindsight.

So I don't know what the alternative is to updating the
language standard.

>
You mean creating your own language standard based on the existing C90
standard.  C90 itself will not change.  Please be clear on that point.

Yes - that's a given. As I acknowledged long ago.

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, at least depending on your definition.

 I recall looking into this last time we
discussed this, and ANSI X3.64 is defined in terms of ASCII.  As far as
I know, no existing terminal or emulator uses the EBCDIC escape
character,

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

A TN3270 link doesn't prevent an EBCDIC ESC from
being sent down the link, so that is used for encapsulation.

Also, my understanding is that that's not the only environment.
The z/OS Unix (which I haven't personally used) apparently
has a termcap or something with EBCDIC ANSI X3.64 in it.
That gets translated to ASCII by some other bit of infrastructure
before it goes over the internet though. But the mainframe side
is EBCDIC - I've been told.

Regardless - even if there were no existing "real" or emulated
terminals that did EBCDIC ANSI - it exists as a theoretical
construct, which is all that matters (to me, anyway).

and I see no need for a terminal that does so.

Even if you see no need for one - I have a "need" for one. How
else is Microemacs 3.6 supposed to work? My fingers are
trained for microemacs, and I wish to use a mainframe.

(Terminals
used with mainframes operate very differently.)

MOST terminals operate very differently.

I prefer to bypass MOST terminals and do whatever is
required to run microemacs on the mainframe.

Even if it takes 30 years to do.

Which it did.

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.

Yeah - I've rethought my position on this.

I want to be able to do an unzip.

On a mainframe, so long as I create the directories I know
I will need in advance (outside of C90), then I can make
unzip unzip into those existing directories.

On a Unix etc system, I don't need to do that preparatory
work.

So the best thing is for mkdir() to "work", either automatically
on Unix, or if appropriate preparation is done on the mainframe.

I don't really care what happens if you don't do the required
preparatory work on the mainframe.

Just like I don't really care what happens on Unix if you run
out of disk space. Or inodes.

My interest is a "properly-prepared and bug-free environment".

That's what I'm trying to make work.

BFN. Paul.