Re: Equality operator overloading in ADA 83

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Bob Duff says

<<Why finite?  The "essence" is that you have a bunch of mutually
exclusive possibilities, and that you cover all the cases, as in:

    case To_Lower(X) is -- Not Ada!
        when "begin" => Do_This;
        when "end" => Do_That;
        when others => Do_The_Other;
    end case;

Ada's choice is to check those rules at compile time, but that's not
part of the "essence".  It's a reasonable choice, though.  Of course,
I've written "when others => raise ...;" sometimes.  But either way, it
doesn't require forbidding strings and other types.  That decision is
based on ease-of-implementation and ease-of-efficient-implementation, I
think.  I'm not arguing that Ada should have this feature ...>>

Here I simply disagree, I find the semantics of checking that all cases
are covered (in the absence of others, one should almost always avoid the
use of others in case statements), to be a fundamental part of the design
semantics of the case statement, that distinguishes it in a fundamental
way from the switch of Algol-60 or in BCPL (I mention this because if I
remember right, BCPL does allow strings, and expect an implementation to
build a hash table where neessary).

In the case of strings, you would *always* have to use others if you want
to preserve this completeness property.

I think that extending case to handle strings would confuse this important
function of the case statement, and since it is only a matter of minor
syntactic sugar (you think one syntax looks better than another), I think
it is unimportant.

I still think that the utility is marginal in real programs, I looked for
the elsif pattern that would correspond to this case sequence, and found
*very* few examples in the millions of lines of code in our regression
suite (always an interesting place to look, since it represents code from
many places).