Extended CASE Statement (Revision 22.2.2015)

Topics related to the use of Oberon language features
Locked
cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Extended CASE Statement (Revision 22.2.2015)

Post by cfbsoftware » Sat Feb 28, 2015 12:26 pm

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

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

Re: Extended CASE Statement (Revision 22.2.2015)

Post by augustk » Mon Mar 16, 2015 8:39 pm

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.

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

Re: Extended CASE Statement (Revision 22.2.2015)

Post by augustk » Mon Mar 16, 2015 8:41 pm

Also, the syntax of the CASE statement in the appendix has not been updated accordingly.

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

Re: Extended CASE Statement (Revision 22.2.2015)

Post by cfbsoftware » Tue Mar 17, 2015 12:29 pm

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.

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

Re: Extended CASE Statement (Revision 22.2.2015)

Post by cfbsoftware » Tue Mar 17, 2015 12:52 pm

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:

Code: Select all

label = integer | string | ident
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.

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

Re: Extended CASE Statement (Revision 22.2.2015)

Post by augustk » Wed Mar 18, 2015 11:22 am

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.

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

Re: Extended CASE Statement (Revision 22.2.2015)

Post by augustk » Wed Mar 18, 2015 11:42 am

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

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

Re: Extended CASE Statement (Revision 22.2.2015)

Post by augustk » Wed Mar 18, 2015 4:10 pm

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.

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

Re: Extended CASE Statement (Revision 18.3.2015)

Post by cfbsoftware » Sat Mar 21, 2015 2:37 am

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.

Locked