Re: Procedure types and dynamic binding

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

From article <5806@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
> 
> Another more direct way to parameterize a change operation is
> to use a procedural variable as a parameter.  Such as:
> 
> generic
>     type ELEMENT_TYPE is private;
> package ...
>     type PRINT_PROCEDURE is procedure (ELEMENT : in ELEMENT_TYPE);
>     procedure CHANGE_PRINT_OPERATION (PRINT_OPERATION : in PRINT_PROCEDURE);
> 
> This allows dynamic specification of statically checked print procedures per 
> instance while the previous example assumed the user knew all allowable 
> procedures during instantiation.

    But now we have a highly changeable system.  What I am asking is,
    "Is there any reason we need this extremely high level of changeability?"

    We are essentially getting into the realm of programs which modify
    themselves, and I tend to think that this power requires extraordinary
    regulation due to the ease with which such a program could modify itself
    to the point that nobody can figure out how it got there in less than
    omega (Ackermann's function) time, much less how to fix it.

    I've suggested earlier that programs should theoretically be able to
    edit source files, cause a recompilation, dump their local knowledge
    into a transition file, invoke the successor on the local knowledge,
    and finally commit suicide, but that this should be done with extreme
    caution. 

    Is there any reason why we need procedural variables in addition to this?



                                           Bill Wolfe

                                    wtwolfe@hubcap.clemson.edu