Oberon Report update

[kevinhely]

The Oberon report has been updated. <= and >= no longer apply to SET arguments AFAICS. (See section 8.2.4)

[cfbsoftware]

The latest revision of the Oberon Language report is 1.10.2013 / 4.3.2016. Changes since Revision 1.10.2013 / 18.3.2015 are:

Section 4 Declarations and scope rules

The following paragraph has been removed:

The scope rule has the following amendments:
1. If a type T is defined as POINTER TO T1 (see 6.4), the identifier T1 can be declared textually
following the declaration of T, but it must lie within the same scope.
2. Field identifiers of a record declaration (see 6.3) are valid in field designators only.

Section 8.2 Operators

set is qualified further:

The set {m .. n} denotes {m, m+1, ... , n-1, n}, and if m > n, the empty set.

Section 8.2.4 Relations

The relations <= and >= no longer apply to the type SET.

Section 9.8 For statements

The TO 'end' expression of the FOR statement is evaluated at every loop.

[augustk]

In section 4, do the removal of the scope rule amendments affect the language in any way? Or did Niklaus simply find them superfluous?

In section 8.2.4, am I correct in assuming that the set inclusion operators were removed because they do typically not correspond to primitive CPU instructions and that they can be implemented with the other set operators?

In section 9.8, am I correct in assuming that the FOR loop guard is now executed in each loop to make its semantics less subtle. Just by looking at a FOR loop and not having the manual at hand, it is not obvious whether the guard will be evaluated only once (as before) or in each loop.

[cfbsoftware]

In section 4, do the removal of the scope rule amendments affect the language in any way?

Not that I can see. The rules were already repeated again in the referenced sections 6.3 and 6.4 so would appear to have been redundant.

In section 8.2.4, am I correct in assuming that the set inclusion operators were removed because they do typically not correspond to primitive CPU instructions and that they can be implemented with the other set operators?

I don't know if that was the primary or only reason. However, I do know that they were implemented very efficiently in the ARM Oberon compilers using the convenient BIC instruction. This performs a bitwise AND of a register value and the complement of an optionally-shifted register value.

In section 9.8, am I correct in assuming that the FOR loop guard is now executed in each loop to make its semantics less subtle. Just by looking at a FOR loop and not having the manual at hand, it is not obvious whether the guard will be evaluated only once (as before) or in each loop.

The limit is evaluated in each iteration of the loop as it always has been in the Astrobe compiler. This behaviour was previously identified in the Astrobe documentation as a language restriction. We will now state instead that it is advisable to use a local variable to store the limit (if not already so) before entering the loop.