Astrobe Forum

The latest version of the Oberon Language Report (Revision 1.10.2013) can now be downloaded from Niklaus Wirth's website.

We will be updating the Astrobe Oberon compiler to conform to this report for the next major release. A summary of the changes follows:

Features Added:

• A new standard data type BYTE compatible with INTEGER. This is the most significant change and is already available in the latest versions of Astrobe.
• A new SYSTEM function called COPY:

  Code: Select all

  SYSTEM.COPY(src, dst, n): copy n consecutive words from src to dst, where src, dst and n are all INTEGERs

Features Changed:

• The second parameter of INC, DEC, INCL and EXCL can now be an expression, not just a constant.

Features Removed:

• The built-in string COPY function.
• The data type LONGREAL and associated functions LONG and SHORT
• The optional second parameter to ASSERT. This will be retained in Astrobe as a language extension.

Hi,

The type BYTE is compatible with type INTEGER, and vice-versa.

I guess that means that a runtime check has to be performed for every assignment to a variable of type BYTE, right (except if the expression is a constant)?

K

Runtime checks such as these (and overflows etc.) are not requirements of the language report. They are left up to the discretion of the implementer. We haven't implemented them in the Astrobe compiler.

We recommend the use of assertions as a problem-detection strategy for programmers who write code that indiscriminately mixes BYTEs and INTEGERs. One possible approach is shown in the IntToByte BYTE example.

Really?

From the Oberon report (section 6, first sentence):

A data type determines the set of values which variables of that type may assume, and the operators that are applicable.

In my opinion BYTE and INTEGER shouldn't be assignment compatible, I don't see the need to assign an integer value to byte and viceversa because they are used for different stuff (except for the integer constant). Maybe Wirth did this to avoid a new type conversion function

As far as I can see the type LONGREAL has only been deleted from section 6.1 in the report; the scale factor D is still in the grammar.

Good point. It is also still referenced in section 3. Vocabulary in assocation with the 'D' suffix on constants.

However, LONGREAL was also removed from the list of pre-defined identifiers in Section 4, and as a possible type of argument to FLOOR in section 10.2.

The SHORT and LONG type transfer functions that were only used with LONGREAL have also been removed.

OK, only section 3 and the grammar need to be corrected then.

Wirth said it was an oversight to leave the "D" business in the report. It will be removed shortly.

That's good as we had already removed it from the compiler