Re: Procedure types and dynamic binding

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

Newsgroups: comp.lang.ada
Subject: Procedure types and dynamic binding
Message-ID: <4204@enea.se>
Date: 30 Dec 88 21:42:42 GMT
Organization: ENEA DATA AB, Sweden
Lines: 84

From Erland Sommarskog:
>Bob Hathaway (rjh@cs.purdue.edu) writes:
>>For yet another Ada 9X extension, I propose procedural variables.   
>>...
>>Procedural variables can
>>avoid the redundant use of case statements by allowing an operation to be 
>>stored within an Adt.     

>I have stated my view before: a language revision should not introduce 
>major changes, but stick to an overview of details that needs refining,
>like character representation. There is one exception, though: if someone

I disagree.  While it's not difficult to design new languages with powerful 
constructs and methodologies it is difficult to get them standardized 
and accepted.  Validated Ada compilers are available on almost every machine
and extending Ada with more modern constructs will at least provide one 
commonly available modern programming language, even if only for designing 
better ones ;-)

>comes up with a fully-fledged extension to give Ada dynamic binding to
>make it a truly object-oriented language, I would whole-heartedily
>support that proposal.

In "Concurrency and Programming Languages" by David Harland, as sited by
Bill, dynamic and static binding are provided as a module option.  I think
this is an excellent idea since most of the literature gives a mind set of 
one type of binding or the other, with the obvious general solution being to
provide both.  Another issue is the level of encapsulation in Ada dynamic
binding should be provided.  Dynamic binding of procedures and functions 
within a package is possible, but so is dynamic binding of packages.  Which
did you mean?

>From this it is clear I think Bob Hathaway's idea should be rejected.
>There are some gains with it, but not suffciently many. We will move
>some tiny step against the O-O paradigm, but we will not be there.

Procedural variables are orthogonal to "O-O" programming, they can
be used for a number of purposes.  Some typical uses are tables of procedural 
variables with generator functions and configuring device driver tables.
Array aggregates are easier to modify than in-line code and initializing
tables of procedural variables with aggregates using named associations would
make programs easy to read.  While tables do not always provide the best 
interface to programmers, I think some circumstances justify their use.

>Just for discussion: If we should make Ada an object-oriented langauge,
>what should we add? Quite obvious seems package types to get classes.
>If we could create several instances of a package, you have what Bob 
>wanted and more. You have data *and* operations stored together. 

Yes, this is the "Completion of the Adt paradigm" Bill mentioned earlier.
In a compilers class at Purdue, I implemented a class type structure which
contained its data and operations including initialization code, and
termination code would have been easy to provide as well.  But these
operations were hardwired into the declaration and a general facility to 
change Adt operations is desirable.  For example, I might want an instance 
to output data in one way but under other circumstances output data in 
another.  If an output operation is implemented as a procedural variable,
I could provide a change_output operation which changes the output operation 
in the Adt. Thereafter, the new print routine would be in effect whenever 
the output operation is invoked.

[ More about the virtues of inheritance... ]

>Now, it is not as easy as this of course. Many detail rules has to
>be thought out. And we would get an unnecessary big language. Would
>we really need the sophisticated system with subtypes and derived
>types? Well, we can't throw it away. 

I don't think procedural variables or class structures will make Ada 
much bigger.  Procedural variables are not complicated in Modula and
from my experience class type structures are not difficult to implement and 
do not complicate the language.  They would, however, provide an incremental 
improvement in data abstraction.

>With the risk of saying something completely obvious: if you want variable
>user-provided operations the following example with a tree-traversing
>illustrates:
>
>   Generic
>      Type Data_type is limited private;
>      With procedure Assign(A : in out Data_type; B : in Data_type);
>      With function "<"(A, B : Data_type) return boolean is <>;
>      With function ">"(A, B : Data_type) return boolean is <>;
>   Package Binary_trees is
>      Type Tree_type is private;        -- A tree with sorted data.
>      Type Node_type is private;        -- A node in such a tree.
>      ...
>      Generic
>         With Procedure Treat(Node : in     Node_type;  
>                              Data : in out Data_type); 
>      Procedure Traverse_forward(Tree : Tree_type);
>

This isn't what I had in mind.  What if variables of type Tree_Type should
be traversed in different ways depending on context?  As above, a case
statement is needed to choose the routine to parameterize Traverse_forward
whenever traversal is invoked.  A scheme is needed to allow Tree_Type Adts to
be programmed with different traversal routines after its declaration has been 
elaborated and without the need for case statements.  If Traverse_forward 
invoked a procedural variable stored within Tree_Type then instances of a
Tree_Type Adt could be reprogrammed to traverse the tree however desired and
a simple call to Traverse_forward would produce the desired result.  I think
this is in harmony with 'O-O' programming, which I usually refer to as Adt
programming, since the operation is stored in the Adt as a procedural variable.

                                           Bob Hathaway
					   rjh@purdue.edu