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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!rjh@cs.purdue.edu From: rjh@cs.purdue.edu (Bob Hathaway) Newsgroups: comp.lang.ada Subject: Re: Procedure types and dynamic binding Message-ID: <5753@medusa.cs.purdue.edu> Date: 31 Dec 88 17:46:44 GMT References: <4204@enea.se> Sender: rjh@cs.purdue.EDU Reply-To: rjh@cs.purdue.edu (Bob Hathaway) Organization: Department of Computer Science, Purdue University List-Id: 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