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/05/01
Message-ID: <dewar.862496910@merv>#1/1
X-Deja-AN: 238689288
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning>
 <335F5971.6375@elca-matrix.ch> <E95y9L.AK1@world.std.com>
 <dewar.861930356@merv> <E973qr.89t@world.std.com>
 <01bc5244$315f1560$28f982c1@xhv46.dial.pipex.com>
 <3365C805.73CF@elca-matrix.ch>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-05-01T00:00:00+00:00
List-Id: <comp.lang.ada>


Mats Weber says

<<The language definition is not based on any concept like "the essence of
the case statement". I don't see any problem with taking the first
alternative that fits, like in a UNIX shell, where case does not follow
the "essence" but is still very useful (OK, I know, we were talking
programming languages :-).>>

Sorry that is wrong, the language design very much has a clear notion of
the design principles behind case. It is NOT just syntactic sugar for
a series of if's. 

I would find a design such as Mats suggests where case is sometimes
just syntactic sugar for if's and sometimes something quite different
depending on whether the expressions are involved to be a far less
coherent design than the current one.

You are proposing introducing a lot of confusion in to the semantic
framework, plus a nasty anomoly where adding the keyword constant
suddely makes a program illegal (yes I know there are acses of that
now). And all you get in return is something that you think is syntactically
a bit neater in some cases that do not frequently arise. I am not even
sure that I agree that it is syntactically neater.

I note that many Ada programmers will prefer

   if x = 3 then ...
   elsif x = 72 then ...
   else ...

to

   case x is
      when 3 => ...
      when 72 => ...
      when others => ...
   end case;

The use of case here, though legal, is conceptually a little bit removed
from the notions of exclusion and coverage that are fundamental to the
case statement -- not technically by conceptually! That is why you
will find many programmers preferring the first form. I am not saying it
should be preferred, and I am not saying the case is wrong, and I do not
particularly want to hear people telling me that they personally prefer
the case here -- of course there are such people too.

The point is that trying to extend the case statement is based on an 
implicit assumption that in the above examples, the more verbose case
statement is preferable.