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!attcan!uunet!lll-winken!ames!mailrus!purdue!rjh From: rjh@cs.purdue.EDU (Bob Hathaway) Newsgroups: comp.lang.ada Subject: Re: Procedure types and dynamic binding Message-ID: <5817@medusa.cs.purdue.edu> Date: 11 Jan 89 02:10:11 GMT References: <5806@medusa.cs.purdue.edu> <4058@hubcap.UUCP> Sender: news@cs.purdue.EDU Reply-To: rjh@cs.purdue.edu (Bob Hathaway) Organization: Department of Computer Science, Purdue University List-Id: > 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? This method is not unusual and can be accomplished by providing an operating system dependent package with the necessary operations. Your suggestion would move this operation into the higher-order domain and could be useful in AI and program generation applications. Retargetable compilers are a case in point. And, speaking of letting proposals stand on their own merits, could we please put the garbage collection issue to rest. Each party could state a final summary of their position, and leave time for consideration before Ada 9X. Thanks, Bob Hathaway rjh@purdue.edu