Because of this topic drift, I'd like to inform you, that I
recently added strings to my version of the Stanford Pascal compiler,
which is a descendent of the Wirth Pascal P4 compiler.
My string implementation uses two length fields in front of every string,
the first being the maxlength field, which tells the maximum length that
the
string can hold, and the second one is the actual length, which
obviously should
be less or equal to the maxlength. Both length fields are two bytes,
like in PL/1 varchars,
so a string can by up to 32767 bytes in length. A string variable
defined as STRING (20)
occupies 24 bytes.
When the string is used in an expression or passed to a function or returned
from a function, a different format is used (so that is can be passed
over the stack).
A string workarea exists to hold the temporary strings while doing
complicated
string expressions like concatenations combined with string function
calls etc.;
the used area is freed (by resetting pointers) every now and then to
prevent
memory leaks.
The string API look much like that from IBMs Pascal/VS. I am preparing a
document
which describes all the technical details about strings in New Stanford
Pascal.
Regarding the problems mentioned below (file buffer, terminal read on
reset (input)
before first writeln), Pascal/VS had functions like TERMIN and TERMOUT,
which
modified the file descriptor to handle terminal output correctly. I did
the same
and inserted a "terminal" flag into the Pascal FCB, so I could fix this
problem, too
(in 2016, already).
The new compiler version (with strings) will be available in the next
few days,
you can get informations here:
http://bernd-oppolzer.de/job9.htm
and here:
https://www.facebook.com/StanfordPascal/
The compiler runs on MVS (z/OS, too), CMS (generating 370 machine code
there),
and on Windows, Linux, OS/2, MacOS (and probably every other system,
that has a C compiler);
on the non-mainframe systems at the moment using a P-Code interpreter.
(The string feature is not yet available for the mainframe version,
because the new P-Codes are not yet understood by the P-Code to 370
translator;
this will probably follow by March 2018).
Kind regards
Bernd
Am 01.02.2018 um 22:22 schrieb Paul Gilmartin:
On 2018-02-01, at 08:37:07, Pieter Wiid wrote:
BTW, those "'Pascal' strings" were not in Wirth's specification of Pascal;
they came later with, e.g. UCSD.
Too true -- Wirth's Pascal was useless for any real work. Character arrays only.
UCSD Pascal had strings and async block I/O. Coming from the mainframe, I
really liked that.
Isn't async block I/O a function of how the runtime library is implemented?
A few decades ago, I participated in development and support of a Pascal RTL
(and compiler) which had asynchronous BSAM and BPAM I/O, transparent to the
application program.
Another problem arose from Pascal's file buffer convention. I judge this a
result of Wirth's fixation on the "structured programming" paradigm of its
time. Apparently he wanted to avoid "END=, ERR=" type signal handlers,
This seriously impacted interactive programming: the program issued a READ
before writing the prompt for it. This was partly alleviated by "lazy I/O",
but the programmer still needed to code in a counterintuitive order.
Borland Turbo Pascal did not implement the file buffer, much to the dismay
of a colleague with whom I shared a program that relied heavily on that
file buffer:
"What is this supposed to do? It doesn't work in Turbo."
"I obeyed the IEEE standard. Turbo doesn't. Complain to Borland."
(But Turbo was pervasive; a de-facto standard.)
POSIX shell has a more rational construct, still signal-free in:
while command; ...; read X; do
...
process record X
...
done
-- gil
