In OpenWatcom, which was the example given in the question, the intr function performs transparent translation between segment values and protected-mode selectors, presumably using DPMI service 0x0002. This means that for example this program runs correctly whether compiled for real or protected mode:
The earliest that was easy to find was ALGOL 68.
After further research, it was unlikely to be any form of BASIC. The original Dartmouth BASIC language was initially released in 1964, but had no string variables. Like ALGOL 68, the fourth version of Dartmouth BASIC was released in 1968, but while it was the first version to have string variables, it did not ...
I did it for a game, but it was a mess.
It was a port of a 2-way fine scroller... by making it a 1-way scroller, we trashed the game pretty badly... it was definitely not faithful to the original. This alone was a disappointment to me and to the client.
Horizontal fine scrolling was simply not on the menu.
It was not achievable. We could horizontal scroll ...
According to https://en.wikipedia.org/wiki/Adaptive_tile_refresh:
CGA (the previous generation of PC graphics hardware) lacks features for scrolling in hardware
so PC games started featuring hardware scrolling only with EGA.
That paragraph is wrong, or better, it lacks a much needed refinement:
CGA did not provide horizontal hardware scrolling. Continue ...
This small example demonstrates a use case for a procedure with unspecified parameters:
2. _INTEGER _ARRAY X[0:10];
3. _REAL _ARRAY Y[1:20];
4. _PROCEDURE SUM(A, B, C, D);
5. _BEGIN _INTEGER I;
6. D := 0;
7. _FOR I := B _STEP 1 _UNTIL C _DO D := D + A[I];
9. _INTEGER I; _REAL R;
I want to address the “Has anyone seen this kind of proto-exceptions in any programming language?” part. In 1972, operators named CATCH and THROW were added to Maclisp (I've reformatted the original announcement for convenience):
There is a new pair of break-away functions: CATCH, a FSUBR [i.e. a “special operator”, in Common Lisp terminology] which merely ...
It should be noted that some implementors of Pascal compilers have, like you, questioned this restriction, and decided to allow alphanumeric labels as a language extension. For example:
Turbo Pascal (mentioned on page 48)
Compaq Pascal (Section 3.2, noting that this is provided "as an extension".)
Free Pascal (Though, because goto is "evil&...
The Algol 60 compiler for the Electrologica X8 was such an implementation. One of its authors wrote a report describing the differences between the X8 compiler and an earlier Algol compiler for the Electrologica X1, which did not support numeric labels; section 5.2.6 discusses how labels and designational expressions in general were handled.
The X8 compiler ...
[Preface: It's about genuine Pascal history, thus I will answer this based on the original 1970 Pascal Manual. Since then many different implementations have been made, so it might not be true for all variations out there]
Why have numeric labels?
To start with, one has to keep in mind that Pascal is intended to do away with labels and goto. It is not to ...
This is not an answer as I don't know the real reason. It is just a comment about parsing
is expected to be followed by either = or a variable type. If a statement were added, then parsing would be a lot more complicated. If, however, you get
it is relatively unique. If it is followed by anything else other than a ...
Pascal can be parsed without using a table of user symbols. If general symbols were allowed as labels, a compiler that encounters a user identifier when a statement is expected would have no way of knowing in advance whether it was a statement label without having to refer to a symbol table.
As for the way forward declarations work, it simplifies the ...
My recollection is that the Burroughs implementation of ALGOL-60 short-circuited, since it recast "and" and "or" as syntactic elements rather than as operators embedded inside expressions.
In view of the increasingly-hostile tone of SE I regret that I am not investing the time to plough through the manuals.
The OED has (behind a paywall) the following definitions and earliest citations for program/programme:
programme | program, n.
a. A sequence of operations that a machine can be set to perform automatically.
1942 J. W. Mauchly Use High Speed Vacuum Tube Devices for Calculating (Moore School of Electr. Engin., Univ. Pennsylvania) in B. Randell Origins ...