Re: Procedure types and dynamic binding

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <5790@medusa.cs.purdue.edu>, by 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.  

     No, all we need is the ability to have pointers which are not bound
     to any specific type.  Most of the time we want to say "pointer to
     SPECIFIC_TYPE", but sometimes we just want to say "pointer".  Given
     the ability to specify an unrestricted pointer, we can implement
     the desired stack (or whatever) of any element type. 
 
> Now, adding polymorphic parameters to Ada would be a sizable extension

     Not true; all we need to do is write procedures which require an
     arbitrary pointer as a parameter, and we're done.

> 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.  

     Quite true, and pointers should be restricted wherever it is reasonable
     to do so, just as ranges should be specified whenever appropriate.

# 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.

     Unless, as I have shown above, a simpler mechanism will suffice.

#>> 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.

   Using the above mechanism, we've eliminated the case statements.

   Now set up your abstraction to provide a "current node" concept,
   along with operations like DESCEND_LEFT, DESCEND_RIGHT, and ASCEND.
   This can be implemented either via parent pointers or via a secret
   stack which holds the path of descent used to reach the current node.



                                           Bill Wolfe

                                    wtwolfe@hubcap.clemson.edu