Re: When a conditional expression is static, where can it be used?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 30.06.10 19:35, Dmitry A. Kazakov wrote:
> On Wed, 30 Jun 2010 07:39:24 -0700 (PDT), Adam Beneschan wrote:
> 
>> On Jun 30, 3:39 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
>> wrote:
>>> A totally meaningless example just to illustrate
>>> the question:  What is it that a compiler must report
>>> for the case statement below, if anything?
>>
>> The choice "Sa" is not covered by any alternative.  Other than that, I
>> don't think there's anything wrong with the CASE statement, and if you
>> had included a "when others =>" alternative I think it would be
>> legal.  I'm not sure what potential problem you were trying to
>> illustrate.

The questions I had asked myself (a little too quick, I suppose)
were along these lines:

Is it possible to invalidate a case construct by simply
changing the value of a static constant used in determining
conditional static case values?  Yes, it is possible even without
conditional expressions, but do these introduce failures that
are much more tricky to straighten out?

If parts of the language will have new (static) possibilities,
what modes of (careful) thinking will these necessitate?

In the case of a case statement, programmers using a static
conditional expression in a case_statement_alternative will be
executing a forward-branching compile time program *and*
need to be backtracking in order to see how other branches of
the case statements will be affected, depending on the
conditional.

The complication is one of the issues that mattered to me,
kind of "second order evaluation" in the programmer's
head (the first order being simple perception of
unconditional values).  It feels a bit like recursive macro
expansion.

All this about static conditional expressions in case_statement_alternative
is probably a somewhat artificial argument, since a conditional
expression in such a place is something Ada programmers will
just not write.  Right?


> Let me propose this one instead: 
> 
>     type DOW is (Mo, Tu, We, Th, Fr, Sa, So);
> 
>     case D is
>        when (if D = Mo then Tu else Mo) => P;
>        when (if D = Tu then Tu else Mo) => Q;
>        when We..So => R;
>     end case;

D: constant DOW := We;
case D is  -- replace D with {We}
   when (if {We} = Mo then Tu else Mo) => P;  -- Mo
   when (if {We} = Tu then Tu else Mo) => Q;  -- Mo
   when We .. So = => R;  -- I should have written Su, sorry
end case;

Tu is not covered, then, is it?  If so, then something else
is equivalent:
> The above is equivalent to:
> 
>     case D is
>        when Tu => P;
>        when Mo => Q;
>        when We..So => R;
>     end case;
> 
> But as Pascal suggested, it should not compile because D is not static. 

I think D is static. D is a constant initialized by a static
function (an enumeration value).


> This wonderful static function can then copied and pasted everywhere you
> wanted to evaluate Gamma at compile time. Is it legal?

Should we have "bigger" static functions?

The 'Constraint or invariant things being worked out for subtypes
are, I guess, potentially static.  How far can one push the
compiler *and* the programmer computing or specifying conditional
expressions, resp.?
(And not have one's head spin too much, or introduce programs
that surprise when changed?)