Van Snyder wrote:
>
> [Van] wrote:
> > > Semantically, CASE is no different from IF.
>
> and Roger Glover wrote:

> > > The existence of an
> > > efficient implementation for an important subset of the usages of a
> > > construct should not be used as an argument against the utility of the
> > > other usages -- it looks more like an excuse than a reason.
> >
> > Actually, it is a "motivation." That is, it is a goal or purpose
> > useful to keep in mind while working with or thinking about the
> > construct.
>
> Bafflegab. I can implement X by method Y. Therefore I can't implement X'?
> Nonsense.

No, your formulation of my opinion is a complete strawman, so of
course it is ridiculous. My thesis could be more accurately stated
as:
    "Method Y was developed to streamline implementation of X.
     So method Y must be carefully reexamined before attempting
     to change it so that it applies to X'."

You have read a much stronger connotation into my statements than
seems reasonable by any stretch of the imagination. I am not
even "opposed" to this idea. I have merely raised objections.
Surely that is not the same as saying something "can't" be done,
or even that it "shouldn't" be done. I would like to think I
still have an open mind on the subject.


> > > Would you expect / hope for use of indexing if you wrote:
> > > SELECT CASE(J) ; CASE(1) ; ... ; CASE(1000000) ; ... END CASE
> > > if there were no other cases? Wouldn't hashing be too much clanking
> > > machinery? I would expect and hope for an IF-tree under-the-covers.
>
> > I suppose it would depend on what was inside the "..."s and how
> > much memory bandwidth is available for instructions. On a Cray
> > vector machine with one simple assignment under each case, there is
> > no doubt you are right; in most codes jump times are a non-issue.
> > On a PC or RISC system with long cache lines and with heaps of code
> > under either of the "..."s, I would hope for partial second-order
> > hashing at least [2].
>
> I had in mind that ... was the stuff _between_ CASE statements, and
> didn't contain any,

That is what I assumed in my response.


> so a jump table would have 1000000 elements, of
> which 2 contain something meaningful.

Only if there was no second-order hashing applied.


> I suspect your compiler turns
> this case into IF (J == 1) THEN ... ELSE IF (J == 1000000) THEN ..., not
> GOTO (10, 30, 30, 30, ............, 30, 30, 20), J ! 999998 30's between
> 10 ... ; goto 40 ! do J == 1 stuff
> 20 ... ; goto 40 ! do J == 1000000 stuff
> 30 STOP 'ERROR'
> 40 CONTINUE ! END CASE

Why do you assume that those are the only two choices? That's
why I took such pains to discuss second-order hashing. You
still speak as if test-and-jump execution (like block IF) and
full first-order hashing (like *your* computed GOTO formulation)
are the only alternatives. They are not!

Having said that, you are probably right that "my" compiler on
Cray vector systems probably uses jump-test for all "scalar"
SELECT CASE constructs (those not contained in a vector loop).
What is the value in making this functionality 5-10% faster
when it represents very little of a typical code?

"My" vector compiler probably uses a vector merge or compress-
index, gather-scatter technique for "vector" SELECT CASE
constructs, the same techniques used for "vector" block-IFs.

"My" compiler on the T3E, the O2K, etc. may very well benefit
from second-order hashing, but I would have to check the generated
code to find out for certain.

Richard Shapiro might be able to tell us directly how the MipsPro
compiler handles this case for O2K and other Mips-based systems.


<Roger's list of possible changes to SELECT CASE snipped>

> Are you really serious,

I am serious that there may be other limitations that one might
wish to remove that would interfere with implementation of the
construct.


> or just trying to reduce the strength of my
> arguments by introducing silly spurious alternatives?

Well, I did not take the time to seriously weigh the merits of
each of these ideas. I should have. I would have eliminated
at least one of these ones from the list.



> 1. <= isn't defined for COMPLEX, so allowing COMPLEX _introduces_ an
> irregularity, it doesn't _remove_ one. That is, only point ranges
> would be allowed.

How is this an irregularity? "<=" is not defined for LOGICAL
either (neither are "==" and "/="), but LOGICAL is already an
allowed type for the construct. And LOGICAL already allows
only "one point ranges". So allowing COMPLEX does *not*
"introduce an irregularity."

With these constraints COMPLEX *would* be of limited utility,
but, then again, without being able to adjust for tolerances,
so is REAL.


> 2. Allow derived type case expressions only if <, <= and == are all
> defined for the type (and accessible).

Does this mean you like this idea? That you don't find it
"silly," or "inconsistent," or "expensive"?

> Same reason as above.

Same rebuttal as above. LOGICAL does not define any of these
and it is allowed now. I can even imagine this to be useful
for encapsulating multiple simultaneous logical choices. If
"<", "<=", etc are not defined, just don't allow ranges (same
as your statement about COMPLEX above).

Is this a good idea? If all the desired relational operators
are defined, it seems to have all the same arguments for and
against that REAL has. If we restrict to derived types for
which all the components are discrete types (directly or
ultimately), there may be a stronger case for derived-type-
valued CASE than for REAL-valued CASE.


> 3. R803: ... IF ( scalar-logical-expr ) THEN
> Allowing array-valued case selector expressions _introduces_ an
> irregularity, it doesn't _remove_ one.

Right. Scrap this one.


> 4. None of <, <=, == are defined on the pointers themselves. Only on
> the things they point at (sometimes).

Again, nor are they defined on LOGICALs.

> I'm not sure what "drop ...
> limitations ... Pointer-valued case expressions?" means. I can
> certainly write SELECT CASE (J) ... even if J has the POINTER attribute.

I am imagining the SELECT CASE (J) checking to see of J is
associated with any of the targets given in the CASEs, and
jumping to that corresponding CASE if so. It would require:
   - "initialization expression" interpreted as "pointer
     initialization expression," restricted to named targets
     and array sections of named targets.
   - special syntax or context requirements to ensure the
     case expression is interpreted as a pointer, not a value.

This is definitely the wildest of my ideas that seems like a
desirable feature at all. Is this functionality any less
desirable than the functionality for REALS? I can certainly
imagine code that should behave differently depending on where
a pointer is pointing. I can imagine wanting to guarantee that
possible pointer target array sections are disjoint. Writing a
module and types to check this disjointness would be much harder
than doing the same for REALs.


> 5. Allowing CASE values to be non-initialization expressions, and
> allowing CASE ranges to overlap remove the useful distinctions
> between IF and CASE (but I _did_ propose one useful extension that
> adds a non-initialization part to a CASE range declaration in 97-114).

So, looking at this paragraph in the surrounding context, you
think allowing "non-initialization expressions" removes the
useful distinction between IF and CASE, and thus is either
"silly," "inconsistant," or "expensive". But then you say you
proposed exactly that in your document!

What conclusion am I supposed to draw from this?

In any case, I too am convinced that changing these restrictions
is a bad idea. But I am not yet convinced that allowing REALs
isn't another bad idea.


> 6. Multiple comma-separated lists of ... would be useful in a fully
> parallel environment.

I am imagining it as a compound condition (".AND." the case-
range comparisons together, only go to the case that matches
all).

Why do you think a comma-separated list of expressions would
make it parallel? Maybe you were imagining more of an ".OR."
combination than an ".AND." combination.

In any case, I gather this is another idea that you like (in a
fully parallel environment)? I must say I don't like it at all!


> > Where does it end?
>
> Just before it gets silly, or inconsistent, or introduces inevitable
> expense for other usage usages (which REAL doesn't).

I am not yet convinced that adding REAL is not at least
"inconsistant."

<snip>


> > The problem with REALs in your scenario is that "range overlap"
> > detectable at compile time could be different than "range overlap"
> > detectable at runtime! Any rule to the contrary would implicitly
> > prohibit (or at least grossly complicate) cross-platform compiling.
> > This reasoning is a straight-forward corollary to the reasoning for
> > the restriction against floating point operations in initialization
> > expressions.
>
> I don't have _any_ syntax to express the desire that I want disjoint
> ranges in the case of REAL selectors.

But you do have the capability of expressing this desire through
modules and types. Range overlaps will not be caught at compile
time, but they will be caught. It would be nice to catch these
problems at compile time. However, in any case where you could
have used a REAL-valued CASE, you could also set things up so
that range-checking is done near the start of the program. This
would minimize the time wasted on an aborted run. There is a
maintenance cost for user code relative to compiler functionality,
however, there are a maintenance costs for the compiler itself.


> I don't know of any cross-platform compilers, or any that anybody plans
> to do.

They may be more common than you think. Every SGI compiler of
which I am aware of allows you to target for whatever MIPS
processors and ABIs (Application Binary Interfaces) were out
at the time of the compiler release, regardless of the processor
on which the compiler is running.

Cray Research also has a long history of cross-compilers within
its vector and MPP systems. In fact, the only compilers available
for the CRAY T3D are cross-compilers.

Both SGI and Cray had these capabilities before the companies
merged.

These are the only cases with which I am thoroughly experienced,
but I seriously doubt my employer is the only one to have this
idea, especially since both "halves" arrived at the idea
independently.

There are other cases as well, but with these my information is
second-hand at best. For example, I offer the following as my
limited understanding of DEC compilers for the DEC "Alpha"
architecture machines; any corrections or clarifications are
welcome.... DEC supports a number of sets of floating point
formats (IEEE-32/64, IEEE-64/128, VAX-F/D, VAX-G/H) within the
"Alpha" architecture, with only one set allowed per program.

In DEC Alpha compilers the set of floating formats is selectable
at compile time, and the whole program must use the same set (so
far, similar to SGI's "ABI" concept). So then, the compiler
must support writing code in all these sets of formats, but the
compiler itself (being a program) knows only one of these as
its "native" set of floating point formats. The situation
has all the characteristics of a cross-compiler, except that all
the format sets coexist within the same CPU. There could be
a separate compiler for each set of floating formats, but I do
not believe that is how they implemented it.


> This is really down in the noise. Even in a cross-compiling
> environment, this is down in the noise, as compared to other problems,
> and at least this one is solvable. Even counting the expense to solve
> it, it's _still_ down in the noise.

I think the expense required to resolve it is what brings it up
above the "noise" as an *issue*. Yes, the problems that need to
be resolved are vanishingly rare end-cases. HOWEVER, the compiler
*could* create wrong or inconsistant code if it does not resolve
them. Thus, adding such a capability would require the compiler
vendor to put in fairly major amounts of work to ensure the
correctness of vanishingly small end cases.

That *DOES NOT* mean that REAL-valued CASE should not be done,
but it does mean that there is a significant argument to be made
by the compiler vendors, one that should not be blithely
dismissed.


> > > If the compilers work correctly, one should be able to prevent overlap
> > > and non-portable behavior by writing
> > > CASE (A <= * <= B) ; ... ; CASE (B < * <= C) ; ...
> > > or CASE (A <= * <= B) ; ... ; CASE (NEAREST(B,1.0) <= * <= C); ...
                                           ^^^^^^^^^^^^^^ fixed
<snip>

> > In the second place, this would require the standard to accept a
> > case value that is not an initialization expression (it contains a
> > REAL-valued intrinsic); where does it end?
>
> This was accepted at meeting 143 (paper 97-250r2),

Granted. My information is outdated. This syntax does not
include a non-initialization expression.

> so it apparently
> ends beyond what Roger thinks is silly.

First, please read carefully. I implied that allowing a non-
initialization expression in a case range was bad idea. I still
think so. However, my argument was undercut *only* by the fact
that the expression in question *is* in fact an initialization
expression. I still think, and the committee still apparently
agrees, that allowing a non-initialization expression in a case
range is a bad idea.

Second, I would very much appreciate it if you would not put
your words into my mouth. I have *never* said that I thought
your proposal was "silly"; that is your word, introduced to
describe my arguments in the message quoted here. I have not
painted you or anyone else here as a clown and I do not intend
to start.


HAVING SAID THAT, 97-250r2 seems to undermine most of the
reasonable objections from compiler vendors. It requires only
the numeric model support that the language already needed for
decimal-to-binary constant conversion, and it avoids requiring
the compiler to reinvent the mathematical model for arithmetic.
It could be used to implement a REAL-valued CASE ranges. The
most serious objections I can imagine at this point are of the
parsing and optimization variety. I think these objections are
weaker, but I do not think *they* should be blithely dismissed
either.

Of course, the case range expressions for this formulation of
REAL-valued CASE are extremely limited compared to what might be
desired for all the intuitive uses of the construct. Simple
arithmetic and the ABS function would be needed to allow a full
range of *safe* expressiveness. I believe adding these *WOULD*
be a major burden, but that does not seem to be what you are
proposing.

Users of REAL-valued CASE might get by without these missing
capabilities. In fact, under these constraints, it seems rather
useful in cases where discretization is the goal.

On the other hand, lack of access to "+", "*", "-", "/", and
"ABS" seems to kill the potential to use the feature safely in
any case where special cases within a continuum-to-continuum
transformation are desired. This is more of a software
engineering point; I would not weigh it as seriously as even
the remaining implementation issues.



-------- Cray Research --------- Roger Glover
-- A Silicon Graphics Company -- http://home.cray.com/~glover


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%