4 ms·

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 orig

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

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).