Re: Procedure types and dynamic binding

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

From article <5793@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
>>     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. 
> 
> But this assumes no type or error checking at all.  By dynamic 
> parameterization I meant with runtime type and error checking.  

    The same runtime type and error checking will occur with
    the unrestricted pointers.  When an operation is applied
    to the object pointed to, the type of that object will
    be used to determine which code to invoke or to prove
    the existence of a run-time error.  Now I see no reason
    why we can't say "pointer to TYPE_1 or TYPE_2 (etc.)",
    thus introducing a new form of restricted pointer, but
    what we are dealing with here is the need to store 
    any type of object whatsoever.  Clearly, unrestricted 
    pointers, with their associated run-time costs, should 
    only be used when their power is absolutely necessary. 

> For static typechecking of data we can use a pointer to a tagged variant 
> record to distinguish types.  This assumes foreknowledge of the types in 
> the variant but at least allows subprograms to distinguish objects.   

    What you describe is a hack which would provide (less cleanly) the
    power provided by the form of restricted pointer described above.

    This is inappropriate to the problem under discussion, which 
    assumes the need to program a polymorphic stack without foreknowledge
    of the types of objects to be stacked.

> but what about dynamically parameterized operations?  Ada has an address 
> type applicable to function and task type addresses but this is 
> implementation dependent and there is no defined typechecking mechanism 
> for the subprogram parameter structure as there is with procedural 
> variables.  Unbound pointers to functions have the same consequences.  
> While tasks can allow procedural abstraction, better is a higher order 
> construct such as procedural variables.

     I have described in earlier articles mechanisms by which the
     desired effects can be achieved in a more intuitive manner.

     Please provide a concrete example in which the provided
     mechanisms would prove inadequate.

>>  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.
> 
> Yes this would work, but leaves programmers to build their own traversal 
> routines.  My idea was to provide a mechanism allowing programmers to specify
> a procedural invocation in a single, simple statement and have the Adt
> select and carry out the operation implicitly.

   But wasn't the basis of your argument the claim that the usual
   preorder, postorder, and inorder traversal schemes may not be
   enough?  The solution to this question is clearly to proceed
   as I have described.  Perhaps you could clarify the problem
   under consideration and the precise nature of your solution...



                                    Bill Wolfe

                             wtwolfe@hubcap.clemson.edu