Oberon Report update
Posted: Fri Mar 04, 2016 5:27 pm
The Oberon report has been updated. <= and >= no longer apply to SET arguments AFAICS. (See section 8.2.4)
A technical support group for Astrobe Oberon users
https://astrobe.com./forum/
Section 8.2 OperatorsThe 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.
The set {m .. n} denotes {m, m+1, ... , n-1, n}, and if m > n, the empty set.
Section 9.8 For statementsThe relations <= and >= no longer apply to the type SET.
The TO 'end' expression of the FOR statement is evaluated at every loop.
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.augustk wrote:In section 4, do the removal of the scope rule amendments affect the language in any way?
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.augustk wrote: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?
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.augustk wrote: 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.