4 ms·

> During my work with Oberon and systems implemented in Oberon, I kept asking myself what properties the language would need to have so that I could use it for

> During my work with Oberon and systems implemented in Oberon, I kept asking myself what properties the language would need to have so that I could use it for my own systems too, without giving up the goal of making it as simple as possible. From here: https://oberon-lang.github.io/2021/07/15/motivation-for-a-new-oberon-version.html https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne... And yet it carries over all of the inanities of the many Oberons before it like: - Four different loops (while, for, repeat, and loop) - Useless distinction between procedures and functions - Randomly selected ASCII symbols to show what is exported and/or read-only - extremely awkward and limited exception handling (you have to call a procedure that cannot hav a return type using a built-in pcall procedure that writes exception info into a variable you pass into it) and so on. All of Oberons are just walking around in circles re-implementing the same weird ideas again, and agian, and agian, and again.

timbit42 4y ago
I like having a few different loops to keep code more readable. I think there should be two at a minimum for whether the condition is before or after the looped code. I agree with the rest, but the rest of the language is great.
- illiarian 4y ago
  > I like having a few different loops to keep code more readable. When they have similar semantics, and are not arbitrarily designed. In Oberon: - while has an elseif statement. Repeat is a do/while, doesn't have an elseif statement - loop is allowed an exit. No other loops are allowed to terminate early. And that is literally the only reason loop exists etc.
  - layer8 4y ago
    The last point is very likely by design: Only when you see a LOOP do you have to worry about early exits. For the other, more common constructs, you instantly know there won’t be an exit somewhere in the middle, and you can reason about its termination behavior solely based on the loop conditional.
    - illiarian 4y ago
      It's not by design, not really. Early Pascal/Modula/Oberons were extremely anal about loops (of any kind) never having any early exits, ever. Then they ran into the real world. So each consecutive version of Oberon either added early returns or removed early returns. Sometimes like clockwork. And also added/removed other types of loops in pursuit of some unspecified ideal of simplicity. You can see part of that history in the overview of differences: https://oberon-lang.github.io/2021/07/16/comparing-oberon+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w... So it's a self-imposed constraint that makes very little sense.
Rochus 4y ago
> extremely awkward and limited exception handling The design is well-balanced and simple, and you can do essentially everything you can do with Java exceptions, just without complicated syntax constructions; see https://oberon-lang.github.io/2022/05/15/towards-exception-handling.html https://oberon-lang.github.io/2022/05/15/towards-exception-h... for more details.
- illiarian 4y ago
  PCALL(P), P cannot have a return type You cannot handle handle exceptions in a block of code without extracting into a procedure... that cannot return anything. Yeah, I doubt you can "do everything you can do with Java expressions. And of course Oberon's syntax construction is more complex: you need to have an external variable that gets populated, you need to match on three different types etc.
  - Rochus 4y ago
    > without extracting into a procedure That's a one second problem; just give back the value via VAR parameter; the design decision is well justified in the referenced article. > do everything you can do with Java expressions "exceptions", not "expressions"; what do you think one cannot do with the Oberon approach? > you need to have an external variable that gets populated That's the Pascal philosophy; even an index variable of a FOR loop has to be declared up front in the declaration section; either you like it or not; personally I prefer the in-place declaration approach, but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java.
    - illiarian 4y ago
      > That's a one second problem; just give back the value via VAR parameter Ah yes. "Just". And these people accuse other languages of having complex syntaxes or complexities in general. > what do you think one cannot do with the Oberon approach I think it's obvious what I wrote. You can't wrap blocks of code, to do that you need to extract it into a proc that among other things (like actual params passed to it needs an additional parameter) needs an awkward `out` parameter etc. Is the result sorta kinda equivalent to Javas? If you squint hard enough, yes > That's the Pascal philosophy; even an index variable of a FOR loop has to be declared up front in the declaration section I know the Pascal philosophy: create awkward verbose languages with useless constraints while claiming it's for the sake of simplicity. > but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java. 1. There's nothing wrong with complexity 2. There a multiple languages that don't have Pascal/Oberon's constraints, decisions, and awkward workarounds which are neither Java nor C++
sedatk 4y ago
> Four different loops I think that having four different loops is better than jumping through four different hoops for different loop styles.
- illiarian 4y ago
  You don't jump through different hoops in most languages [1]. In Oberons you jump through the hoops because only `loop` is allowed to have `exit`, for example. Which is a constraint for the sake of constraints. Repeat is a do/while, but it doesn't have while's elseif statement. Again, because reasons. And so on. Oberon is nothing but hoops instead of loops. [1] Go's decision to not include do/while is on par with Oberon's decisions for loops: stupid and unreasaonable.
  - sedatk 4y ago
    I wasn't trying to defend Oberon per se but separate goal-specific loop constructs. Yes, not having `exit` in other loop types sounds problematic.
flykespice 4y ago
> - useless dinsctintion between procedures and functions? Uh? care to elaborate?
- illiarian 4y ago
  A proc is a function with no return. A function is a function that returns something. Oberon+ keeps it's predecessors' idiotic distinction, but takes it one step further: both functions and procedures are decalred with `proc` or `procedure`, functions are `proc`s that have a return type. And yet: - procedure calls don't have to specify parameters apparently, but function calls must specify all parameters - functions cannot be used in Oberon+'s weird exception handling. [1] You do a call with `PCALL(res, P, args)` where res is a variable that will hold the result of the exception if it happened, and P is the procedure. You cannot pass functions (aka procedures which have a return type) As the spec so wonderfully says [2], --- start quote --- There are two kinds of procedures: proper procedures and function procedures. The latter are activated by a function designator as a constituent of an expression and yield a result that is an operand of the expression. Proper procedures are activated by a procedure call. A procedure is a function procedure if its formal parameters specify a result type. Each control path of a function procedure must return a value. --- end quote --- [1] https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#exception-handling https://github.com/oberon-lang/specification/blob/master/The... [2] https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#exception-handling https://github.com/oberon-lang/specification/blob/master/The...

timbit42 4y ago

I like having a few different loops to keep code more readable. I think there should be two at a minimum for whether the condition is before or after the looped code. I agree with the rest, but the rest of the language is great.

illiarian 4y ago
> I like having a few different loops to keep code more readable. When they have similar semantics, and are not arbitrarily designed. In Oberon: - while has an elseif statement. Repeat is a do/while, doesn't have an elseif statement - loop is allowed an exit. No other loops are allowed to terminate early. And that is literally the only reason loop exists etc.
- layer8 4y ago
  The last point is very likely by design: Only when you see a LOOP do you have to worry about early exits. For the other, more common constructs, you instantly know there won’t be an exit somewhere in the middle, and you can reason about its termination behavior solely based on the loop conditional.
  - illiarian 4y ago
    It's not by design, not really. Early Pascal/Modula/Oberons were extremely anal about loops (of any kind) never having any early exits, ever. Then they ran into the real world. So each consecutive version of Oberon either added early returns or removed early returns. Sometimes like clockwork. And also added/removed other types of loops in pursuit of some unspecified ideal of simplicity. You can see part of that history in the overview of differences: https://oberon-lang.github.io/2021/07/16/comparing-oberon+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w... So it's a self-imposed constraint that makes very little sense.

Rochus 4y ago

> extremely awkward and limited exception handling The design is well-balanced and simple, and you can do essentially everything you can do with Java exceptions, just without complicated syntax constructions; see https://oberon-lang.github.io/2022/05/15/towards-exception-handling.html https://oberon-lang.github.io/2022/05/15/towards-exception-h... for more details.

illiarian 4y ago
PCALL(P), P cannot have a return type You cannot handle handle exceptions in a block of code without extracting into a procedure... that cannot return anything. Yeah, I doubt you can "do everything you can do with Java expressions. And of course Oberon's syntax construction is more complex: you need to have an external variable that gets populated, you need to match on three different types etc.
- Rochus 4y ago
  > without extracting into a procedure That's a one second problem; just give back the value via VAR parameter; the design decision is well justified in the referenced article. > do everything you can do with Java expressions "exceptions", not "expressions"; what do you think one cannot do with the Oberon approach? > you need to have an external variable that gets populated That's the Pascal philosophy; even an index variable of a FOR loop has to be declared up front in the declaration section; either you like it or not; personally I prefer the in-place declaration approach, but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java.
  - illiarian 4y ago
    > That's a one second problem; just give back the value via VAR parameter Ah yes. "Just". And these people accuse other languages of having complex syntaxes or complexities in general. > what do you think one cannot do with the Oberon approach I think it's obvious what I wrote. You can't wrap blocks of code, to do that you need to extract it into a proc that among other things (like actual params passed to it needs an additional parameter) needs an awkward `out` parameter etc. Is the result sorta kinda equivalent to Javas? If you squint hard enough, yes > That's the Pascal philosophy; even an index variable of a FOR loop has to be declared up front in the declaration section I know the Pascal philosophy: create awkward verbose languages with useless constraints while claiming it's for the sake of simplicity. > but the language would become much more complex and it doesn't make sense to just rebuild C++ or Java. 1. There's nothing wrong with complexity 2. There a multiple languages that don't have Pascal/Oberon's constraints, decisions, and awkward workarounds which are neither Java nor C++

sedatk 4y ago

> Four different loops I think that having four different loops is better than jumping through four different hoops for different loop styles.

illiarian 4y ago
You don't jump through different hoops in most languages [1]. In Oberons you jump through the hoops because only `loop` is allowed to have `exit`, for example. Which is a constraint for the sake of constraints. Repeat is a do/while, but it doesn't have while's elseif statement. Again, because reasons. And so on. Oberon is nothing but hoops instead of loops. [1] Go's decision to not include do/while is on par with Oberon's decisions for loops: stupid and unreasaonable.
- sedatk 4y ago
  I wasn't trying to defend Oberon per se but separate goal-specific loop constructs. Yes, not having `exit` in other loop types sounds problematic.

flykespice 4y ago

> - useless dinsctintion between procedures and functions? Uh? care to elaborate?

illiarian 4y ago
A proc is a function with no return. A function is a function that returns something. Oberon+ keeps it's predecessors' idiotic distinction, but takes it one step further: both functions and procedures are decalred with `proc` or `procedure`, functions are `proc`s that have a return type. And yet: - procedure calls don't have to specify parameters apparently, but function calls must specify all parameters - functions cannot be used in Oberon+'s weird exception handling. [1] You do a call with `PCALL(res, P, args)` where res is a variable that will hold the result of the exception if it happened, and P is the procedure. You cannot pass functions (aka procedures which have a return type) As the spec so wonderfully says [2], --- start quote --- There are two kinds of procedures: proper procedures and function procedures. The latter are activated by a function designator as a constituent of an expression and yield a result that is an operand of the expression. Proper procedures are activated by a procedure call. A procedure is a function procedure if its formal parameters specify a result type. Each control path of a function procedure must return a value. --- end quote --- [1] https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#exception-handling https://github.com/oberon-lang/specification/blob/master/The... [2] https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc#exception-handling https://github.com/oberon-lang/specification/blob/master/The...