Rationale behind difference between Oberon family of languages.

[sinu.nayak2001]

Hi,

What is the rationale behind the difference between languages,
oberon and oberon 2
oberon and oberon 7
oberon and active oberon ?

As far as I know, Oberon is a nice procedural programming language.
Oberon 2 is Oberon with object orientation features.
Active Oberon is Oberon with concurrency.

If Active Oberon came after Obron2 in timeline, why then concurrency was no added to Oberon2? Why going back to procedural Oberon was preferred to add concurrency?

Another thing is when Modula2 was well suited for object oriented programming, why oberon was choosen to be procedural? Keeping this apart, if we say oberon was more or less similar to modula, then object oriented programming should still be possible with Oberon too. Why then there was a need to go for Oberon2?

Another story is for Oberon 7 which again branched off from Oberon...not from any of its ancestors!

Hope we will have some discussion here to clear these doubts.


Sincerely,
Srinivas

[cfbsoftware]

Another thing is when Modula2 was well suited for object oriented programming

I don't believe it was. What makes you think that?

Another story is for Oberon 7 which again branched off from Oberon...not from any of its ancestors!

Different individuals have different projects to work on and different objectives. The addition of features to Oberon that led to Oberon-2 was primarily the work of Hanspeter Mössenböck. Similarly, the evolution from Oberon-2 to Active Oberon was the work of Patrik Reali.
 
The other branch: Oberon-07 (by Wirth) evolved from Oberon (by Wirth) via Oberon-SA (by Wirth). Oberon-SA was designed particularly for the programming of real time embedded control systems with limited resources and Oberon-07 follows that trend.

[staubesv]

As far as I know, Oberon is a nice procedural programming language.
Oberon 2 is Oberon with object orientation features.
Active Oberon is Oberon with concurrency.

Active Oberon is Oberon-2 with concurrency support and "more" object orientation.

[Bernhard T.]

Active Oberon is Oberon-2 with concurrency support and "more" object orientation.

hmm, according to the abstract of Andreas Signer project (see http://www.cs.inf.ethz.ch/group/gutknecht/stud_work/1997WS_02/) there is also a different syntax, but Oberon-2 can be seen as a semantic subset of Active Oberon.

It switched from "type bound bound procedures" (in Oberon-2) to objects in Active Oberon.

I don't know if Andreas Signers O2Active converter is still existing. If not I might dig on ...

regards
   Bernhard

[sage]

O2Active converter

It's quite interesting.

[Bernhard T.]

It's quite interesting.

sorry for the late answer: Do you want me to dig?

As far as i remember, I got a version from patrik Reali around 6 years ago.
Does anyone at ETHZ have a newer version?

regards
    Bernhard

[nicholas]

I am surprised by some of the changes Prof. Wirth made to Oberon-07:

  1) Removing the "else" from the case statement. In the document about Oberon-07
      I noticed that he implemented a software trap for the "case" construct failing to
      accomodate all possibilities. This seems like a bit extreme. He does not provide
      any explanation for the change, even in the document about the differences
      between Oberon and Oberon-07. An "else" statement has an obvious semantics:
      it's an alternative whose guard is the negation of the disjunction of all the other
      case conditions.
  2) Elimination of the "loop" statement. Wirth claims that this does not have a consistent
      logical semantics, but, as long as the loop is limited to having just one "exit", it can
      be transformed to a "while" loop by repeating the code before the "exit" above the
      "while" and after the code following the "exit" and before the loop's end.
  3) Requiring functions to have only a single "return" statement. If someone took it into
      their head to implement a compiler with last-call-optimization, i.e. transforming a
      final call into a jump instead, needing to funnel the control flow to a single return point
      would force the last-calls to be so no longer.   By the way, I have always been
      curious as to why more imperative language compilers don't implement LCO--anyone
      have any comments?

     --    Nicholas
         

[leledumbo]

• Doesn't he add that due to its lack in original Pascal? Has he found a correct reason not to have it?
• Well.. the problem with while loop (and thus the introduction of explicit infinite loop) is sometimes the exit point check comes in the middle of the loop body, though it's not really a problem. One can always use the old good solution: while-true-do and repeat-until-false
• I'd rather say it's better not to have it at all. The Pascal way is good. It ensures function ends where it should end

[cfbsoftware]

Problems associated with the use of ELSE in CASE statements often occur when debugging / maintaining / extending software. If the software was originally written by someone else, problems are even more likely.

1. Valuable information is missing. Did the author really intend to omit the missing cases or was it just an oversight?

2. Future modifications to other areas of the software may require extra cases to be added to an existing CASE statement. If they are overlooked, they will just drop through the ELSE clause and the mistake is less likely to be detected during testing.

In practice not having an ELSE clause is no big deal. If the missing cases are disjoint they can be handled with a single additional CASE selection. It is then clear to the reader exactly which cases the author did not intend to handle e.g.

Code:

CASE index OF
1, 5, 8..12, 91: DoSomethingElse() |
...

Alternatively, if the CASE statement handles a contiguous range of values minVal ..maxVal then smaller, but possibly slower, code is likely to result from:

Code:

IF (index < minVal) OR (index > maxVal) THEN
   DoSomethingElse()
ELSE
   CASE index OF ...

[Dsar]

Honestly I don't understand the problem about ELSE in the CASE statement.
The CASE statement is implemented as lookup/jump/.. table or something like this.
It is always a "static" construct, if extensibility is important, why not just remove the
CASE statement at this point?

(Off Topic: Chris, do you have a link where one can download the Oberon-07 compiler
for ARM written by Wirth?)

[cfbsoftware]

(Off Topic: Chris, do you have a link where one can download the Oberon-07 compiler
for ARM written by Wirth?)

Our Astrobe system uses Wirth's Oberon-07 compiler which we ported to Windows to target NXP's LPC2000-family of ARM microcontrollers. You can download an evaluation copy from the link below.

However, I suspect you are referring to the original Oberon source code of the compiler. If so you should contact Wirth if you want to enquire about its availability.