Updated Oberon Language Report (Revision 1.10.2013)

Topics related to the use of Oberon language features
augustk
Posts: 54
Joined: Mon Sep 05, 2011 5:21 pm
Location: Sweden

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by augustk » Wed Oct 30, 2013 2:02 pm

As far as I understand the compatibility between the type BYTE and the type INTEGER means that e.g. for x: BYTE the statement x := x + 1 is valid but not INC(x). Is this correct?

In section 9.1 (Assignments) we are told that:
The type of the expression must be the same as that of the designator.
In the example x := x + 1 above, x + 1 has type INTEGER and x has type BYTE. Therefor I suspect that the section needs to be amended with an exception saying that an expression of type BYTE can be assigned to a variable of type INTEGER and vice versa. What do you think?

kevinhely
Posts: 29
Joined: Wed May 18, 2011 3:35 am

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by kevinhely » Wed Oct 30, 2013 5:26 pm

That's good as we had already removed it from the compiler
Heh heh! Ditto!

kevinhely
Posts: 29
Joined: Wed May 18, 2011 3:35 am

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by kevinhely » Wed Oct 30, 2013 5:29 pm

I suspect that the section needs to be amended with an exception...
I guess that's covered by
The type BYTE is compatible with the type INTEGER, and vice-versa.
in Section 6.1 of the report.

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

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by augustk » Thu Oct 31, 2013 9:50 am

Even if the types are compatible they are not "the same".

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

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by cfbsoftware » Thu Oct 31, 2013 12:41 pm

For most cases we are treating compatible as meaning the same as far as BYTE and INTEGER are concerned in the Astrobe Oberon compiler that conforms to the 1.10.2013 revision. e.g. the following are allowed where b is a BYTE and i is an INTEGER:

Code: Select all

INC(i)
INC(b)
INC(b, i)
INC(i, b)
b := i + 1
i := b + 1
i := b + i
b := i + b
Note that the shift operations LSL, LSR, ASR, ROR and SYSTEM.EOR can have parameters that are INTEGERs or BYTEs but the result is always an INTEGER.

For more information see the topic New language extension: BYTE data type
Last edited by cfbsoftware on Fri Nov 01, 2013 10:07 pm, edited 2 times in total.
Reason: Revised shift operations

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

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by cfbsoftware » Sat Mar 01, 2014 6:07 am

kevinhely wrote:Wirth said it was an oversight to leave the "D" business in the report. It will be removed shortly.
It has now been removed.

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

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by augustk » Tue Mar 11, 2014 9:23 am

It has now been removed.
The "D" in the scale factor has bee removed from section 3, yes, but not from the grammar in the appendix. The reason for this according to Wirth is that he didn't want to "invalidate old data sets".

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

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by augustk » Tue Mar 11, 2014 9:36 am

Niklaus Wirth updated the report in February (unfortunately without changing the date). In the current revision
1. the scale factor with "D" has been partially removed
2. all kinds of variables can now be exported (in read-only mode)
3. the grammar symbol for constant declarations is now consistently named ConstDeclaration.

Have I missed anything?

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

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by augustk » Wed Mar 12, 2014 10:53 am

In yesterday's update SYSTEM procedures supported by the RISC processor was also added.

dsar
Posts: 8
Joined: Wed Oct 10, 2012 9:12 pm

Re: Updated Oberon Language Report (Revision 1.10.2013)

Post by dsar » Wed Mar 12, 2014 5:36 pm

augustk wrote:Have I missed anything?
The SET type is now:
The sets of integers between 0 and an implementation-dependent limit.

Locked