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:

and here:

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


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

-- gil

Reply via email to