Re: Anybody in US using ADA ? One silly idea..

["Robert I. Eachus" <rieachus@attbi.com>]

As I read through this thread, I noticed widespread ignorance on both 
sides of the way Ada generics actually work.  This is not surprising, as 
the essential magic is "hidden" in plain sight in what seems like a 
textual substitution shorthand.  But as anyone who actually implements 
Ada generics can tell you, it is anything but textual substitution.

Ada generics have four places where binding of parameters occurs.  At 
the point of the generic declaration, any bindings that occur are 
compile time bindings with respect to names, and can be to static or 
dynamic values:

generic function Foo(X: in Integer := Read) return Integer is...

The second set of bindings occurs in the body.  Although it is possible 
for the binding in the body of a generic to be to a different instance 
of a name than in the specification, good programming practice strongly 
deprecates that possibility.  However, it is common for new names to be 
visible in the body, and to be used.

The third set of bindings occurs at the point of instantiation.  This is 
where the generic parameters are bound.  A classic example of using this 
binding occurs with sorts:

     generic
        type Element is private;
        type Element_Array is array (Integer range <>) of Element;
        function ">" (L,R: Element) return Boolean;
     procedure Sort(EA: in out Element_Array);

Now an instantiation of Sort passing "<" instead of ">" will sort in 
descending instead of ascending order.  Of course for convenience, the 
specification above is normally written as:

     generic
        type Element is private;
        type Element_Array is array (Integer range <>) of Element;
        function ">" (L,R: Element) return Boolean is <>;
     procedure Sort(EA: in out Element_Array);

The 'is <>' allows the function ">" to be defaulted and left out of the 
instantiation.  This is where the magic--or snakepit--occurs, depending 
on whether you are a user or implementor.  Instead of 'is <>' I could 
have written 'is Standard.">"' and insured that the default would be to 
the predefined greater than operation for Integer.

But with the 'is <>', I get the ">" function for Integer visible at the 
point of instantiation.  This can be in a nested call, and the binding 
can actually be to some ">" in a (run-time) enclosing declarative part. 
  In other words, implementing the 'is <>' notation correctly requires 
support for upward closures.  But there is worse (from an implementors 
point of view) to come.

The fourth point of binding is at the call.  This is where the names of 
the formal parameters are bound to the actuals.  But notice that the 
environment of the call need not be that of instantiation, in fact, 
quite often it is not.  This means that if you try to implement Ada 
using displays, generics sometimes require passing multiple displays as 
implicit parameters.  (Ouch!  Ask Randy Brukardt for details, he has 
actually implemented it.)

Should you use this Lisp style richness of closures when programming in 
Ada?  I have found very few cases where the power was worth the 
documentation effort to make sure any maintainers understood what was 
going on.  The one exception has been in displaying appropriate error 
messages during debugging of parsers. ;-)