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/26
Message-ID: <dewar.862110493@merv>#1/1
X-Deja-AN: 237638711
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning>
 <01bc5244$315f1560$28f982c1@xhv46.dial.pipex.com> <E99CHB.2B9@world.std.com>
 <dewar.862088714@merv> <E99vJH.LJM@world.std.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-26T00:00:00+00:00
List-Id: <comp.lang.ada>


i<<Sure, an Ada compiler could do that.  But none does (that I know of).
That's not because it's infeasible.  I think it has more to do with
expectations.  Nobody would expect that optimization, so nobody does it.
And programmers who want to compare strings build hash tables, or
whatever other technique they think is appropriate, by hand.  They don't
*expect* the compiler to do it for them.

With a case statement, expectations are different.  I certainly expect a
jump table, when appropriate, rather than a series of compares.  If case
statements allowed strings, but still required static choices, I'm not
sure what to expect -- but a series of elsifs certainly isn't the only
reasonable choice.>>


Typically a compiler would just transform the two structures into something
common anyway, so I really don't see this. Since you mention Setl, it does
indeed have general case statements, but no attempt is made to optimize
the fancy ones. Yes, we all expect a jump table for the discrete case, but
as you say, there are no built in expectations for the string case.

The reason that no Ada compiler does that optimization for elsif's is not
because it is hard, it is because it is not worth doing -- and I don't
think optimizing the case would be any more worth while, it is simply
too unusual an idiom (a case against a large number of strings that are
staticaly known at compile time) to be worthwhile. I have trouble thinking
of any reasonable examples ...