From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c3a7c1845ec5caf9
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Equality operator overloading in ADA 83
Date: 1997/04/27
Message-ID: <dewar.862141915@merv>#1/1
X-Deja-AN: 237699765
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning>
 <335F5971.6375@elca-matrix.ch> <E95y9L.AK1@world.std.com>
 <dewar.861930356@merv> <E973qr.89t@world.std.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-27T00:00:00+00:00
List-Id: <comp.lang.ada>


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).