Relational operations on discrete types / visibility

Relational operations on discrete types / visibility

[Frank Prindle]

In the following simple example, the second if statement fails because the
"=" is not visible, but the semantically equivalent case statement compiles
without error (yet still implicitly requires the "=" or some combination of
relational operations on the discrete type color_type).  

Since the compiler can generate code for the case statement, it can clearly
generate code for the second if statement (i.e. there is no ambiguity to
resolve).  So why the inconsistency? (personally, I don't think either
statement should fail, but if one must, both should).  The compiler is
VADS 6.0.3.

Sincerely,
Frank Prindle
Prindle@NADC.navy.mil

-------------------------------example follows--------------------------
package color_pkg is
        type color_type is (RED, GREEN);
end color_pkg;

with color_pkg;
with text_io;
procedure color_test is
        color:color_pkg.color_type:=color_pkg.GREEN;
begin
        if(color_pkg."="(color,color_pkg.GREEN))
        then
                text_io.put_line("GREEN");
        end if;

        if(color = color_pkg.GREEN)			--ERROR HERE (EXPECTED)
        then
                text_io.put_line("GREEN");
        end if;

        case color is					--WHY NO ERROR HERE?
                when color_pkg.GREEN=>text_io.put_line("GREEN");
                when others=>null;
        end case;
end color_test;
--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

Re: Relational operations on discrete types / visibility

[pa.dec.com!nntpd2.cxo.dec.com!bonmot!wallace]

Frank.Prindle@bbs.oit.unc.edu (Frank Prindle) writes:
: In the following simple example, the second if statement fails because the
: "=" is not visible, but the semantically equivalent case statement compiles
: without error (yet still implicitly requires the "=" or some combination of
: relational operations on the discrete type color_type).  
: 
: Since the compiler can generate code for the case statement, it can clearly
: generate code for the second if statement (i.e. there is no ambiguity to
: resolve).  So why the inconsistency? (personally, I don't think either
: statement should fail, but if one must, both should).  The compiler is
: VADS 6.0.3.
: 
: Sincerely,
: Frank Prindle
: Prindle@NADC.navy.mil
: 
: -------------------------------example follows--------------------------
: package color_pkg is
:         type color_type is (RED, GREEN);
: end color_pkg;
: 
: with color_pkg;
: with text_io;
: procedure color_test is
:         color:color_pkg.color_type:=color_pkg.GREEN;
: begin
:         if(color_pkg."="(color,color_pkg.GREEN))
:         then
:                 text_io.put_line("GREEN");
:         end if;
: 
:         if(color = color_pkg.GREEN)			--ERROR HERE (EXPECTED)
:         then
:                 text_io.put_line("GREEN");
:         end if;
: 
:         case color is					--WHY NO ERROR HERE?
:                 when color_pkg.GREEN=>text_io.put_line("GREEN");
:                 when others=>null;
:         end case;
: end color_test;
: --
:    The opinions expressed are not necessarily those of the University of
:      North Carolina at Chapel Hill, the Campus Office for Information
:         Technology, or the Experimental Bulletin Board Service.
:            internet:  bbs.oit.unc.edu or 152.2.22.80


Frank,

	The problem is that the function, as you have in your code above,
is equality "=" on the types.  The case statement evaluates and expression
based on the type not on a function of the type of the expression.

Hope this helps!

Richard Wallace
Digital Equipment Corporation
301 Rockrimmon Blvd. South
CXO2-1/7A
Colorado Springs, CO 80919-2398
(719)548-2792
<wallace@cookie.enet.dec.com>

	"The opinions expressed are my own, Unlce Ken or Uncle Bob
	 may, or may not, agree with me.