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!pacbell!ames!ncar!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Procedure types and dynamic binding Message-ID: <4018@hubcap.UUCP> Date: 5 Jan 89 10:02:24 GMT References: <5753@medusa.cs.purdue.edu> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >From article <5753@medusa.cs.purdue.edu>, by rjh@cs.purdue.edu (Bob Hathaway): > Erland writes: >>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 ;-) I have to agree with Bob. Since old Ada and new Ada would be fairly similar, automatic translators would probably be highly effective should the need arise. >>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. Um, hold on there. I cited Harland primarily as an example of extreme steps which would provide maximum support for abstraction, and I support Harland's view that departures from the state of maximum expressiveness must bear the burden of proof, but I also noted that there are certain situations in which I think a convincing case can be made in this direction. Most languages, though, go much too far in their restriction of expressiveness, including Ada. (Still, Ada is the best language available, all things considered.) As far as dynamic binding goes, I think there is a need to provide the ability to have a program edit (or generate) a piece of source code, compile that code (including any necessary recompilations), dump any necessary local knowledge for its successor to load in, initiate its successor, and finally kill itself off, but I see no need to go any farther than that. Harland gives a rather eloquent statement of why systems must be self-modifying, and this argument is convincing. But dynamic binding (as I understand the term) is "too changeable", like the uncontrolled change which occurs in some inheritance-oriented languages. Ada's compilation control facilities enable controlled change; they provide firewalls against modification which serve to require that all aspects of the propagating change(s) are considered throughout the system, and this is a very good thing which we should not dispense with lightly. Even the scheme I've described should be applied only with extreme caution. > [...] 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. Other than doing things as I've described above, another way would be (assuming that New Ada expands the idea of a specification to include any accesses to externally defined objects/definitions) to have the output procedure examine its environment to decide what to do. > I don't think procedural variables or class structures will make Ada > much bigger. Procedural variables are not complicated in Modula [...] 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. > This isn't what I had in mind. 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. Bill Wolfe wtwolfe@hubcap.clemson.edu