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!ucbvax!bloom-beacon!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: <4062@hubcap.UUCP>
Date: 11 Jan 89 14:24:42 GMT
References: <5816@medusa.cs.purdue.edu>
Sender: news@hubcap.UUCP
Reply-To: wtwolfe@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From article <5816@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
> [much verbiage deleted...] 
> 
> class STACK is
>   type OPERATION_TYPE is procedure;
>   procedure OPERATION (ELEMENT : in polymorphic;...);
>   procedure CHANGE_OPERATION (NEW_OPERATION : OPERATION_TYPE);
>   function  GET_OBJECT return polymorphic;
> end STACK;

    First, let's clarify the terminology: a STACK is an example of a type.
    A class is a group of related types.  Thus, APPLE and ORANGE are types,
    and FRUIT is a class of types.  OBJECT is the class of all possible types.

    Despite the request that you be generous with the comments, no indication
    was given as to what OPERATION has to do with the stack.  Let's assume
    that it is some operation that one wishes to apply to every item in the
    stack.  Then we encounter problems in that OPERATION has only an "in"
    parameter, and therefore cannot modify its parameter.  But we'll overlook
    this too, and ask: If we're looking at objects which need to be modified,
    1) what are they doing hidden away inside a stack?  2) why can't we just
    have a stack of pointers, and write a procedure which will serially read
    the stacked objects and update what they point to? and 3) what if the user
    wants to keep N different operations which could be applied to all items
    in the stack, without the bother of continuously invoking CHANGE_OPERATION?

    The mechanism whereby a program could edit source files, cause a rec
    recompilation, transfer its local knowledge to its successor, and
    then destroy itself is appropriate to an environment where code
    modifications are infrequent; the system transitions from one well-defined
    state to another, and the source code always represents the current
    state of the system.  Additionally, optimized code can be generated.
    Procedural variables would encourage excessive rates of change, and
    would greatly complicate the problem of code optimization.

    The idea of modifying the display routine of a graphical object 
    through procedural variables has no merit.  What should be modified
    is a standardized data structure such as a bit-map or list of endpoints.
    This is analogous to the inappropriate use of recursion (vs. iteration).

> If Ada is to continue remaining viable as a state-of-the-art programming
> language then incremental extensions such as procedural variables [...]

    Ada is a state-of-the-art applications programming language, not
    a state-of-the-art research language.  Perhaps a more appropriate
    approach to procedural variables would be to incorporate them into
    a research language and look for a) efficient implementations,
    including code optimization, and b) realistic situations in which 
    the use of procedural variables is effectively not optional.   



                                            Bill Wolfe

                                     wtwolfe@hubcap.clemson.edu