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
