Re: Procedure types and dynamic binding

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

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