Oberon Report update

Topics related to the use of Oberon language features
Post Reply
kevinhely
Posts: 29
Joined: Wed May 18, 2011 3:35 am

Oberon Report update

Post by kevinhely » 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)

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Oberon Report update

Post by cfbsoftware » Sat Mar 05, 2016 3:28 am

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.
Last edited by cfbsoftware on Sat Mar 05, 2016 9:54 pm, edited 1 time in total.
Reason: Latest revision is 1.10.2013 / 4.3.2016

augustk
Posts: 54
Joined: Mon Sep 05, 2011 5:21 pm
Location: Sweden

Re: Oberon Report update

Post by augustk » Thu Mar 17, 2016 9:36 am

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
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Oberon Report update

Post by cfbsoftware » Thu Mar 17, 2016 1:08 pm

augustk wrote: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.
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?
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 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.

Post Reply