From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
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
List-Id: <comp.lang.ada>

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 langauge 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
comes up with a fully-fledged extention to give Ada dynamic binding to
make it a truly object-oriented langauge, I would whole-heartedily
support that proposal.

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

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. 
  But this doesn't suffice. This far we have just constructed task
types doesn't cost us a context change. We must have inheritance in
some way. How tell which other package types we inherit from? The 
WITH clause is not useful; it merely tells us which types we intend
to declare objects of. USE? Maybe. Doing USE on a package type to 
get all exported operations directly visible is of no interest. We 
should USE the package variable instead. But for inheritance we want 
all attributes, also those who do not appear in the specification 
part (or?), and particulary we probably want to have access to 
private types internal structure. So best would be a particular 
INHERIT clause.
  Multiple inheritance? That doesn't seem to be any problem. Ada
already has RENAMES which here could serve to remove clashes.
  Dynamic binding? We must be able to redefine a inherited operation.
There is no current construct for that in Ada so a REDEFINES clause
has to be added. (Rather useful is also deferred procedures that
inhereting packages *must* define, Ada more or less has this concept.) 
  We are about satisfied by now. Probably we need delaration a la
Eiffel, but if we could make all the rest, this would be no problem.
  Procedure types could be added for completeness, but doesn't feel
that necessary with all we added above.

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. 

Oh, one we need one more thing if go this way. Yes, you guessed it:
Garbage collection.

>It also allows individually parameterizable and 
>reprogrammable Adts since operations can be provided to alter the Adts actions
>or structure.  Generic subprogram parameters can only allow Adts to be set 
>once for any instantiation.  I use procedural variables and function pointers
>in Adts frequently when programming in languages other than Ada and am 
>convinced they are an elegant way to model Adt actions.

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);

(By the way, an example like the one above should be added to the validation
suite if it's not already there. A PC compiler I played with choked on the 
code above, and I believe it is/was validated.)
-- 
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.
sommar@enea.se