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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!S1-B.ARPA!jmb From: jmb@S1-B.ARPA (Jeff Broughton) Newsgroups: net.lang.ada Subject: procedures as parameters Message-ID: <8606062056.AA04312@s1-b.arpa> Date: Fri, 6-Jun-86 16:56:40 EDT Article-I.D.: s1-b.8606062056.AA04312 Posted: Fri Jun 6 16:56:40 1986 Date-Received: Sun, 8-Jun-86 04:46:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: You asked for an example of an algorithm where subprograms as parameters are needed. You correctly identified the issue as being whether or not the identity of the procedure can be known at compile time. My favorite example is that of a terminal interface. A user logs into a computer system and then tells it what type of terminal is to be used. Several systems that I know of implement this kind of runtime binding by having a set of procedure values that implement various functions, e.g. clear_screen, put_line, etc. Initially, the system initializes the variables for a generic terminal. When the user makes his selection, the routines implementing the protocols specific to the terminal type are assigned to the variables, and presto(!), terminal I/O is transformed for another type. Many might argue that this could be accomplished in other ways. The Unix termcap facility is one way; though I would argue that, in effect, they accomplish the result by implementing pointers to interpretive code. Another is to have a global variable which defines the type of the terminal, and have each terminal interface procedure to examine the terminal type variable and dispatch to the corresponding routine. Ignoring issues of efficiency, my objection to the second approach is that it requires the person who writes the terminal library to have full knowledge of all the terminals that are to be supported, or equivalently, that to add a new terminal type to the system, you have to modify the code. This is terrible modularity. The usual counter argument is that for my example the names of all the terminal types and hence the code for all the terminal types must be in the system anyway; the difference is that it is on top of the terminal library rather than below. This is true in most computer systems that we use today. Being an old Multics programmer, however, I am use to the notion of dynamic linking, where I can load a subroutine by name from the file system and call it without every knowing its name at compile time. Fundamentally, what I am arguing is that the notion of "device independence" requires procedure variables. Sure, you can get around them, but you really wish that you didn't have to. By the way, this is really the same argument as in the earlier message about the implementation of key-bindings in EMACS that appeared earlier on Info-Ada. Only the terms have been changed to aid the unfamiliar.