inner modules (nested units), which more or less served as a information hiding building block within a module/unit.
Pioneered by Brinch Hansen.
I always thought they were a bit overly stylistic, and I never really used them/had a use for them. That said, I'm not that big on information hiding other than some basic level between modules. IMHO it is a good concept that is often take way too far.
Some interesting runtime library concepts that are however dated now - textwindowing unit, more than Crt, less than FV
- a cooperative multitasking unit
Not sure those were in the language, either as defined by Wirth or in the later (ISO?) standard. Might have been TopSpeed-specific, although coroutines were in the language.
It is the book (by N. Wirth, but a Dutch translation) about the standard, but it says it is not part of the standard. But many compilers had them. (terminal, (text)window(ing) etc). I liked the TS Window module.
It describes coroutines exclusively in the context of standard procedures. (no language enhancements for them, so could be purely library). Correct me if I'm wrong, it has been a while since I did anything with that.
The water is a bit muddied here by stuff that I think Wirth brought back to Europe from PARC, which were later sold by Logitech (e.g. a mouse toolkit which was the first time I'd seen the source of an input event message handling loop).
The book lists that too, modules Terminal, FileSystem, InOut, RealInout, Windows, TextWindows, GraphicWindows, CursorMouse, Menu, Storage, Mathlib0.
case sensitivity. Not an advantage IMHO
Arguable. Even if it's not mandatory, I'd like a way of enforcing it purely to improve documentation etc.
Use formatters or IDEs, doesn't belong in a language. The old joke was that Wirth simply wanted twice the amount of one digit variables.
unsigned types by default (jury is still out on this one too)
Note that both signed integers and unsigned cardinals were supported.
In retrospect, maybe I understood it wrong at the time. In Pascal, signed being default means that mixed expressions get promoted to the signed integer that is a superset of both, so that the full range is supported.
Maybe it matters less in M2 what default is because it does not allow mixing of integer types (and likewise real types) like Pascal and C do. You need to explicitely cast and thus indicate the calculation type.
But above all I really missed a decent way of handling strings. M2 string handling was too manual for my taste. I changed to FPC in 1998, but kept maintaining the old codebases till 2001-2003, when I move to win2000, first at work, later at home, and the dos binaries started very slow under windows 2000, so I ported the code to FPC.
I think that M2 strings were /defined/ as being zero-terminated. Can't remember whether they were based on element zero, but they were basically arrays of chars rather than having special handling.
Afaik the only special handling was assignment of literals to array of chars even if sizes mismatched. The convention was zero terminated except when the length of the string matched the size of the allocation, then it was _not_ zero terminated. But static arrays only.
In assembler it was repne scasb iirc. with cx the size of the allocation. If it ran to completion, it was the non zero terminated case, if it didn't, there was a zero termination and the remainder in cx gave the position from the back.
Oberon was a minimalistic OOP follow up to Modula2, and IMHO too limited to function.
Agreed, from what little I know of it. I'd add that as I understand it there's also an Oberon GUI environment which still has its enthusiasts, but the real successor to M2 was M3 etc.
Yeah. The M3 compilers I saw were sad, so I mostly ignored that language.