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, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!tut.cis.ohio-state.edu!rutabaga.cis.ohio-state.edu!edwards From: edwards@rutabaga.cis.ohio-state.edu (stephen edwards) Newsgroups: comp.lang.ada Subject: Re: procedural variables Message-ID: <88642@tut.cis.ohio-state.edu> Date: 19 Feb 91 20:33:07 GMT References: <9102110959.aa23851@PARIS.ICS.UCI.EDU> <662@esosun.UUCP> <24590@neptune.inf.ethz.ch> <2834@cod.NOSC.MIL> <1991Feb16.141232.1@elcgl.epfl.ch> Sender: news@tut.cis.ohio-state.edu Reply-To: stephen edwards Organization: Ohio State University Computer and Information Science List-Id: In article <1991Feb16.141232.1@elcgl.epfl.ch> madmats@elcgl.epfl.ch writes: >After all, the 'need' for procedure variables has only >become serious since people have been trying to interface x-toolkits >with Ada (callbacks), but does that mean that callbacks are the right >way of doing it ? This isn't quite correct. Ironically, procedure _variables_ (in Ada) aren't even needed for X callbacks, as virtually all Ada-to-C X interfaces illustrate. One only need pass an indirect reference to an Ada procedure on to the C code. For this purpose, there isn't need of Ada-manipulable procedure variables. (this would not be true when interfacing to an all Ada implementation of X, of course.) But this statement, and a few of the past articles on this thread which point out that generics can be used in place of many forms of procedure variables, misses what may be the heart of the 'need.' Remember "table- driven programming"? Maybe you learned it by a different name, like "data-driven computation", computing with "dispatch tables", or something else. But the point is that real, live procedure variables _can be placed in data structures_. These data structures can be manipulated in arbitrary ways, and the final result can be passed to something that is, at heart, an interpreter. Now, that final "interpreting" routine has programmable semantics. What actions it performs can be controlled simply by placing procedure variables pointing to new routines into the data structure. How much the semantics can be altered (and how easily) is determined by the actual structure of the "table", how it is manipulated, the interpretation strategy, etc. This is a fairly conventional, but very powerful technique. It allows one to completely separate the "driver"/interpreter/execution framework from the "action routines"/"evaluation functions/etc, and pushes the time at which the binding between these two distinct parts are made off until run-time. It's common in highly programmable/configurable software tools which load a configuration file when they are run--this file is basically a description of the interpreted data structure in some abstract form. Without procedure variables, you can't completely separate the driver from the action routines. This makes the software somewhat less flexible and also more difficult to maintain. A few posters have hinted at such "alternative" uses for procedure variables, but no one had quite come right out and said it (if they did and I missed it, I apologize for the redundancy). -- Steve Stephen Edwards U.S. mail: 372 Jones Tower e-mail : edwards@cis.ohio-state.edu 101 Curl Drive home phone: (614)-293-0842 Columbus, OH 43210