I have realized that "CARDINAL behaves just like.." was a correction of a contradiction with
(2) in Mika's original post. But there is another inconsistency.
(2) is a purely syntactic rule about type equality. But the implementation
uses a deep semantic rule elsewhere in evaluating bounds expressions. Consider:
MODULE Main
; CONST Ten = 10
; CONST Nine = 9
; TYPE T1 = [ 0 .. Ten ]
; TYPE T2 = [ 0 .. Nine + 1 ]
; VAR V1 : T1
; PROCEDURE P2 ( VAR F2 : T2 )
= BEGIN (P2)
END P2
; BEGIN (Main)
P2 ( V1 ) (* This compiles without error. *)
END Main
.
I.e., T1 and T2 are considered equal types.
Do we want to do away with (2)? Are there other places where this distinction is relevant?
It sounds like (2) is an obstacle for Mika. I don't think of any way eliminating it would
undermine existing code.
BTW, the syntactic inequality rule applies to all 7 predefined discrete types and their full subranges.
I have realized that "CARDINAL behaves just like.." was a correction of a contradiction with
(2) in Mika's original post. But there is another inconsistency.
(2) is a purely syntactic rule about type equality. But the implementation
uses a deep semantic rule elsewhere in evaluating bounds expressions. Consider:
MODULE Main
; CONST Ten = 10
; CONST Nine = 9
; TYPE T1 = [ 0 .. Ten ]
; TYPE T2 = [ 0 .. Nine + 1 ]
; VAR V1 : T1
; PROCEDURE P2 ( VAR F2 : T2 )
= BEGIN (P2)
END P2
; BEGIN (Main)
P2 ( V1 ) (* This compiles without error. *)
END Main
.
I.e., T1 and T2 are considered equal types.
Do we want to do away with (2)? Are there other places where this distinction is relevant?
It sounds like (2) is an obstacle for Mika. I don't think of any way eliminating it would
undermine existing code.
BTW, the syntactic inequality rule applies to all 7 predefined discrete types and their full subranges.