Re: The "()" operator revisited.

["Robert I. Eachus" <rieachus@comcast.net>]

Dmitry A. Kazakov wrote:

> Maybe. In your example generic_array_shuffle might be inherited or
> overridden. In which case the compiler could take an advantage of
> knowing the constraint. Then, the procedure could be inlined, so again
> the compiler could re-instantiate its body. Presently optimizations of
> this kind are not required. I would define some of them in RM to make
> them mandatory.
> 
> Futher, if neither applied, what would be a penalty as compared with a
> variant based on a generic procedure, which instances are reusing the
> body? Actually in the static case, either the constraints have to
> propagate into the body, making its reuse impossible, or not. Whether
> the body itself is a template or a class-wide is of little matter.

Rather than addressing what you said, let me describe how generics 
actually work in Ada.  There are four times when actuals are bound to 
formals, when the generic is compiled, when the generic instantiation is 
compiled (and notice that these first two can happen in any order), when 
the generic instantiation is elaborated at run-time, and when a generic 
subprogram, or a subprogram declared in a generic package is called.

The case that most people forget is the third one, instantiation happens 
at run-time, but before any calls.  In particular the "is <>;" construct 
is pretty weird, see 12.6(15). The matching rule says to do the matching 
at the place of the instantiation, and means it.  But as you can see 
above, instantiation occurs at run-time.  It turns out that you can 
determine at compile time which textual subprogram declaration will 
match an "is <>;" by looking at static closures, but the actual instance 
of that declaration will be determined at run-time.  In other words you 
know which textual declaration will match, but the actual match may be 
to one of the instances of this subprogram in the upward closure of the 
point of instantiation.   A fancy way of saying that the binding occurs 
at run-time, and may require passing a context.

But what you normally have to treat as determined at run-time are the 
constraints.  If the elaboration of a generic involves evaluating 
constraints, each time the instantiation is elaborated the constraints 
may be different from the time before.  You can use nested generics to 
cause "freezing" of constraint values at different points.  It all 
sounds very hard, but in practice it is easy.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush