I also have fond memories of BBS door games and software, a large portion of which was built with Pascal.
I digress: but it's nice to reminisce about those old days.
I also have fond memories of BBS door games and software, a large portion of which was built with Pascal.
I digress: but it's nice to reminisce about those old days.
And even better with Delphi that additionally had better rapid UI creation possibilities than Visual Basic, and on top of that, differently than Visual Basic, produced a self containing executable, not depending on anything external.
This is actually a (minor) issue i have with Lazarus - the executable files do not depend on anything, but they are too large (~2MB minimum nowadays, if you remove all debug info, etc) so if i want to create several "small" utilities that focus on one thing instead of a multi-tool, i waste a lot of space (and most importantly nowadays, bandwidth).
At least with Delphi you can compile the executable with the runtime library as a separate file to be shared among the programs (my guess is that they wanted to do something the VB shared runtime, but it didn't seem to catch on as nobody used it like that).
Now that you mention and I think about it, as VB was compiled to the p-code and depended on the big common runtime which executed it, it can be seen as one Windows-specific spiritual precursor of... Java.
Both Microsoft's P-Code and Java were really inspired by UCSD Pascal which only emitted P-Code to be executed by a runtime they implemented quickly in a lot of systems (including the original IBM PC).
Yes, and I've actually experimented with UCSD Pascal on a 8-bit machine (Apple II). Turbo Pascal was, of course, much faster on it (using Z-80 card).
The result of assigning an integer > 255 to a byte is unspecified; it's the same with numeric overflow in arithmetic operations.
Yes, the result is unspecified, that is what i'm talking about: it doesn't specify what it happens, meaning that the implementations will have to figure that out themselves, potentially in an incompatible manner (although in general implementations do try to be compatible with each other, but this is by communicating among themselves and trying to fill the holes in the Oberon-07 spec).
Similar question is also about pointers, what happens if you try to use p^ when p is nil? Do you try to access whatever address nil represents? Do you abort?
C has the notion of undefined behavior and it is explicitly mentioned, but Oberon-07 doesn't mention this at all meaning that implementations need to make those decisions.
1. restrict the freedom of compiler writers. On very small systems, for instance, array bound checking may not be implemented,
2. make programmer rely on non-obvious behaviour/results which makes programs harder to understand and maintain,
3. make the language specification more complicated.