Re: Procedure types and dynamic binding

[rjh@cs.purdue.EDU (Bob Hathaway)]

>> I don't think procedural variables or class structures will make Ada
>> much bigger.  Procedural variables are not complicated in Modula [...]
>
[Bill Wolfe responds]
>    But Modula doesn't have generics.  Using the combination of generics
>    and the class abstraction outlined in my earlier article, I think
>    we'll get more power, with better readability.
>

Yes, class structures with generics would provide good data abstraction.
This would allow classes to be statically parameterized by types, variables, 
constants, and subprograms.  Generics are good for setting an Adt once, such as
a stack which is parameterized by its element type and a print subprogram.  
But what about dynamic parameterization?  For dynamic parameterization of data,
polymorphic parameters to Adt operations are needed to allow the greatest 
expressiveness.  An example is a stack of any element type which could be
provided by polymorphic parameters to an insert subprogram.  For dynamic 
parameterization of operations, procedural variables are needed.  An example
is a stack which can change its print operation as described previously.

Now, adding polymorphic parameters to Ada would be a sizable extension but 
adding procedural variables would be almost trivial.  Admittedly, Adt 
designers can provide a plethora of operations and programmers can use case 
statements to choose among them but this puts greater burden on the programmer
since they must now select the correct operation throughout their code.  Also,
static generic parameterization is desirable in certain cases such as in the
stack example above when the element type is known in advance and the type
system can statically perform strong typechecking for correctness.  But the
flexibility of dynamic parameterization allows maximum expressiveness 
and greater power, and so "the burden of proof" has to be made against
dynamically parameterized operations.  Since static generics and dynamic
parameterization are not mutually exclusive, both could be provided.

>> This isn't what I had in mind.  What if variables of type Tree_Type should
>> be traversed in different ways depending on context?
>
>    Just make basic traversal operations a part of your abstraction.
>

But this calls for case statements throughout the program to determine which 
operation to call, as mentioned above.  For maximum expressiveness, I might
want to set instances with particular traversal operations and then use a
single operation invocation at a later point in the program which will invoke
the correct operation for all instances, reducing redundant code and allowing 
maximum expressiveness.


					Bob Hathaway
                                        rjh@purdue.edu