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!uflorida!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: <4042@hubcap.UUCP> Date: 8 Jan 89 19:01:59 GMT References: <5793@medusa.cs.purdue.edu> Sender: news@hubcap.UUCP Reply-To: wtwolfe@hubcap.clemson.edu List-Id: >From article <5793@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway): >> all we need is the ability to have pointers which are not bound >> to any specific type. Most of the time we want to say "pointer to >> SPECIFIC_TYPE", but sometimes we just want to say "pointer". Given >> the ability to specify an unrestricted pointer, we can implement >> the desired stack (or whatever) of any element type. > > But this assumes no type or error checking at all. By dynamic > parameterization I meant with runtime type and error checking. The same runtime type and error checking will occur with the unrestricted pointers. When an operation is applied to the object pointed to, the type of that object will be used to determine which code to invoke or to prove the existence of a run-time error. Now I see no reason why we can't say "pointer to TYPE_1 or TYPE_2 (etc.)", thus introducing a new form of restricted pointer, but what we are dealing with here is the need to store any type of object whatsoever. Clearly, unrestricted pointers, with their associated run-time costs, should only be used when their power is absolutely necessary. > For static typechecking of data we can use a pointer to a tagged variant > record to distinguish types. This assumes foreknowledge of the types in > the variant but at least allows subprograms to distinguish objects. What you describe is a hack which would provide (less cleanly) the power provided by the form of restricted pointer described above. This is inappropriate to the problem under discussion, which assumes the need to program a polymorphic stack without foreknowledge of the types of objects to be stacked. > but what about dynamically parameterized operations? Ada has an address > type applicable to function and task type addresses but this is > implementation dependent and there is no defined typechecking mechanism > for the subprogram parameter structure as there is with procedural > variables. Unbound pointers to functions have the same consequences. > While tasks can allow procedural abstraction, better is a higher order > construct such as procedural variables. I have described in earlier articles mechanisms by which the desired effects can be achieved in a more intuitive manner. Please provide a concrete example in which the provided mechanisms would prove inadequate. >> Now set up your abstraction to provide a "current node" concept, >> along with operations like DESCEND_LEFT, DESCEND_RIGHT, and ASCEND. >> This can be implemented either via parent pointers or via a secret >> stack which holds the path of descent used to reach the current node. > > Yes this would work, but leaves programmers to build their own traversal > routines. My idea was to provide a mechanism allowing programmers to specify > a procedural invocation in a single, simple statement and have the Adt > select and carry out the operation implicitly. But wasn't the basis of your argument the claim that the usual preorder, postorder, and inorder traversal schemes may not be enough? The solution to this question is clearly to proceed as I have described. Perhaps you could clarify the problem under consideration and the precise nature of your solution... Bill Wolfe wtwolfe@hubcap.clemson.edu