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: bobduff@world.std.com (Robert A Duff)
Subject: Re: Equality operator overloading in ADA 83
Date: 1997/04/25
Message-ID: <E973qr.89t@world.std.com>#1/1
X-Deja-AN: 237297862
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning>
 <335F5971.6375@elca-matrix.ch> <E95y9L.AK1@world.std.com>
 <dewar.861930356@merv>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-04-25T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.861930356@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>I don't see what you mean. The semantic esssence of a case statement is
>that there is a finite set of possibilities which must b covered. Otherwise
>it is mere syntactic sugar for elsif ...

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 -- it's a
useful feature, but doesn't really match the semantic level of Ada.
(When you start having super-high-level features, you can no longer
guess how efficient the implementation will be.  E.g. if there are a lot
of branches, will the compiler generate a hash table of some sort?  A
perfect has function?  Who knows?)

The above is clearer than:

    if To_Lower(X) = "begin" then
        Do_This;
    elsif To_Lower(X) = "end" then
        Do_That;
    else
        Do_The_Other;
    end if;

for two reasons: you know the case expression is evaluated exactly once,
so you needn't worry about side effects, and you know that exactly one
of the case alternatives applies, whereas with an "elsif" chain, it
might be the case that two of the alternatives are True, but the
programmer carefully ordered them so that you never get to the second
one.  In other words, you know these useful facts when you see "case",
whereas with "elsif" chains, you need to study the code carefully to
know these facts, if they are true in a particular case (or rely on
comments, which might lie, or might not be there).

- Bob