3 ms·

The designer of Pascal, prof. Niklaus Wirth, evolved the language into Modula-2 and then Oberon. Oberon is a refreshingly lean language. The specification is on

The designer of Pascal, prof. Niklaus Wirth, evolved the language into Modula-2 and then Oberon. Oberon is a refreshingly lean language. The specification is only 17 A4-pages long: https://www.miasap.se/obnc/oberon-report.html https://www.miasap.se/obnc/oberon-report.html

Crinus 7y ago
Note that this is Oberon-07, not Oberon, the latter is a bit different (and there are other Oberons). Also the spec is indeed small, but it doesn't address qustions like what happens when you assign an integer to a byte that is outside the range that a byte can represent.
- augustk 7y ago
  Oberon-07 is simply the latest version of Oberon, like Python 3 is the latest version of Python. Other non-Wirthian Oberons are best viewed as forks of the original. The result of assigning an integer > 255 to a byte is unspecified; it's the same with numeric overflow in arithmetic operations.
  - Crinus 7y ago
    You'll find that a lot of people who work with Oberon explicitly state the dialect/variant they use (they are different dialects, not just versions) and Oberon usually refers to either the original or the language family. 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).
    - augustk 7y ago
      The programmer should make sure that an integer is within the range of a byte before assigning it to a byte variable. It's no more complicated than that.
      - Crinus 7y ago
        The question is what happens if the programmer doesn't do that. If you are implementing a compiler, what do you do in that case? Are you using whatever is the first or last byte in memory (depending on the machine endianess)? Are you wrapping the value around to keep it consistent between implementations? Are you generating code that aborts the program? 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.
        augustk 7y ago
        If you are implementing a compiler you do what makes most sense for the target language/machine. On the other hand, if you specify exactly how each ill-defined operation should be handled you 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.
        Crinus 7y ago
        Or you can simply type "Integer to byte conversion and nil dereference are machine dependent" (or implementation dependent if you prefer, but the point is to have something).

Crinus 7y ago

Note that this is Oberon-07, not Oberon, the latter is a bit different (and there are other Oberons). Also the spec is indeed small, but it doesn't address qustions like what happens when you assign an integer to a byte that is outside the range that a byte can represent.

augustk 7y ago
Oberon-07 is simply the latest version of Oberon, like Python 3 is the latest version of Python. Other non-Wirthian Oberons are best viewed as forks of the original. The result of assigning an integer > 255 to a byte is unspecified; it's the same with numeric overflow in arithmetic operations.
- Crinus 7y ago
  You'll find that a lot of people who work with Oberon explicitly state the dialect/variant they use (they are different dialects, not just versions) and Oberon usually refers to either the original or the language family. 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).
  - augustk 7y ago
    The programmer should make sure that an integer is within the range of a byte before assigning it to a byte variable. It's no more complicated than that.
    - Crinus 7y ago
      The question is what happens if the programmer doesn't do that. If you are implementing a compiler, what do you do in that case? Are you using whatever is the first or last byte in memory (depending on the machine endianess)? Are you wrapping the value around to keep it consistent between implementations? Are you generating code that aborts the program? 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.
      - augustk 7y ago
        If you are implementing a compiler you do what makes most sense for the target language/machine. On the other hand, if you specify exactly how each ill-defined operation should be handled you 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.
        Crinus 7y ago
        Or you can simply type "Integer to byte conversion and nil dereference are machine dependent" (or implementation dependent if you prefer, but the point is to have something).