Page 1 of 1
Extended CASE Statement (Revision 22.2.2015)
Posted: Sat Feb 28, 2015 12:26 pm
by cfbsoftware
The latest revision of the Oberon Language Report (1.10.2013 / 22.2.2015) now includes the definition of the extended CASE statement which first appeared as a new feature of the FPGA RISC Oberon compiler used in Project Oberon 2013.
The type T of the case expression (case variable) may also be a record or pointer type. Then the case labels must be extensions of T, and in the statements Si labelled by Ti, the case variable is considered as of type Ti.
The type extension example included with Astrobe contains the following code snippet:
Code: Select all
IF shape IS Square THEN Out.String("Square")
ELSIF shape IS Rectangle THEN Out.String("Rectangle")
ELSIF shape IS Circle THEN Out.String("Circle")
ELSIF shape IS Ellipse THEN Out.String("Ellipse")
END
The next release of Astrobe will support the new extended CASE statement. That will allow this code snippet to be written more simply as:
Code: Select all
CASE shape OF
Square: Out.String("Square")
| Rectangle: Out.String("Rectangle")
| Circle: Out.String("Circle")
| Ellipse: Out.String("Ellipse")
END
Re: Extended CASE Statement (Revision 22.2.2015)
Posted: Mon Mar 16, 2015 8:39 pm
by augustk
As far as I understand when the CASE expression is INTEGER or CHAR the program is halted if no label matches the value. That doesn't seem to be the case in your example.
Re: Extended CASE Statement (Revision 22.2.2015)
Posted: Mon Mar 16, 2015 8:41 pm
by augustk
Also, the syntax of the CASE statement in the appendix has not been updated accordingly.
Re: Extended CASE Statement (Revision 22.2.2015)
Posted: Tue Mar 17, 2015 12:29 pm
by cfbsoftware
augustk wrote:As far as I understand when the CASE expression is INTEGER or CHAR the program is halted if no label matches the value. That doesn't seem to be the case in your example.
Your observation is correct. The Language Report does not prescribe what the behaviour should be if no label matches the value - that is left to be decided by the implementer. When the CASE expression is INTEGER or CHAR the version of Astrobe currently in development does halt. However, when the CASE expression is POINTER OR RECORD there is no action - the same as the corresponding IF THEN ELSIF example. This latter behaviour is compatible with the Project Oberon 2013 compiler.
Re: Extended CASE Statement (Revision 22.2.2015)
Posted: Tue Mar 17, 2015 12:52 pm
by cfbsoftware
augustk wrote:Also, the syntax of the CASE statement in the appendix has not been updated accordingly.
What update are you thinking of? As far as I can see the existing syntax is sufficient.
However, there may otherwise be a need to modify the CASE statement label syntax anyway from:
to:
Code: Select all
label = integer | string | qualident
The current syntax does not allow for labels that are constants directly imported from other modules. I can't think of any good reason why that should not be allowed.
Re: Extended CASE Statement (Revision 22.2.2015)
Posted: Wed Mar 18, 2015 11:22 am
by augustk
The Language Report does not prescribe what the behaviour should be if no label matches the value - that is left to be decided by the implementer.
To me that seems like a very dangerous approach. It's not at all clear that an unmatched value results in undefined behaviour. A programmer may rely on the CASE statement doing nothing when the value is not matched by a label; after all that's what happens with a corresponding IF ELSIF cascade. That the program is halted for INTEGER and CHAR and not halted for pointers and records in the same compiler makes it even more confusing.
Re: Extended CASE Statement (Revision 22.2.2015)
Posted: Wed Mar 18, 2015 11:42 am
by augustk
What update are you thinking of? As far as I can see the existing syntax is sufficient.
The productions
CaseLabelList and
label have changed from
Code: Select all
CaseLabelList = LabelRange {"," LabelRange}.
label = integer | string | ident.
to
Code: Select all
CaseLabelList = LabelRange {"," LabelRange} | qualident.
label = integer | string.
but the grammar in the appendix still has the old definitions. The intention is to invalidate pointer/record CASE statements with more that one label in a label list.
Unfortunately, the following is no longer valid:
Code: Select all
CONST c0 = 0; ... c9 = 9;
n: INTEGER
CASE n OF
c0, c3, c7..c9: S1; ...; Sn
| c1, c2, c4..c6: T1; ...; Tn
END
The CASE statement has to be written as
Code: Select all
CASE
c0: S1; ...; Sn
| c1: T1; ...; Tn
| c2: T1; ...; Tn
| c3: S1; ...; Sn
| c4: T1; ...; Tn
| c5: T1; ...; Tn
| c6: T1; ...; Tn
| c7: S1; ...; Sn
| c8: S1; ...; Sn
| c9: S1; ...; Sn
-- August
Re: Extended CASE Statement (Revision 22.2.2015)
Posted: Wed Mar 18, 2015 4:10 pm
by augustk
Luckily, Niklaus Wirth just changed the grammar (revision 18.3.2015) from
Code: Select all
CaseLabelList = LabelRange {"," LabelRange} | qualident.
label = integer | string.
to
Code: Select all
CaseLabelList = LabelRange {"," LabelRange}.
label = integer | string | qualident.
Re: Extended CASE Statement (Revision 18.3.2015)
Posted: Sat Mar 21, 2015 2:37 am
by cfbsoftware
augustk wrote:Code: Select all
CaseLabelList = LabelRange {"," LabelRange}.
label = integer | string | qualident.
Great news - that was a quick response! We have now implemented support for qualified identifiers as CASE statement labels in the Astrobe compiler.