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!watmath!clyde!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.ada
Subject: Re: Procedure types and dynamic binding
Message-ID: <35339@think.UUCP>
Date: 11 Jan 89 17:51:21 GMT
References: <5816@medusa.cs.purdue.edu> <4062@hubcap.UUCP>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
List-Id: <comp.lang.ada>

In article <4062@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>    Ada is a state-of-the-art applications programming language, not
>    a state-of-the-art research language.  Perhaps a more appropriate
>    approach to procedural variables would be to incorporate them into
>    a research language and look for a) efficient implementations,
>    including code optimization, and b) realistic situations in which 
>    the use of procedural variables is effectively not optional.   

I'm really beginning to wonder what universe you're coming from. :-)

Procedure variables are hardly a research topic these days.  They've
been in production use for decades.  And I can't think of any reason
why any decent compiler implementor wouldn't be able to implement them
efficiently (the only inefficiency I know of is minor - procedures
assigned to variables must get their own stack frame, rather than
being able to share its parent block's stack frame - and does not
exist if procedure assignment is restricted to top-level procedures).

They've been in use in the Lisp programming world for years.  They are
great for AI applications in which objects must have highly variable
active properties.  Simple object-oriented systems can be implemented
using either "upward closures" (functions that remember the lexical
environment from which they were returned) or structures that contain
data and a procedure object.

They are used quite effectively on Multics, which has extended PL/I to
support procedure variables.  The most obvious use is in the
device-independent I/O library.  The structure that represents an I/O
stream mostly contains procedure objects that implement the
device-specific portion of each I/O operation.  When you call the
device-independent routines they dispatch through the appropriate
component of the stream structure.  The components that represent
operations that are not appropriate (either because of the type of
device or the state of the stream) can be filled in with procedures
that return appropriate error indications.  But all of the above can
be done with extra flags in the structure and CASE statements.  Where
it really comes in handy is when you allow new device drivers to be
linked in on the fly (Multics has been doing dynamic linking for over
twenty years, and there's a system call to explicitly invoke the
dynamic linking mechanism and return a procedure object).

I guess this doesn't provide any more fundamental capabilities than
the runtime recompilation mechanism you've mentioned.  But I sure
wouldn't want to use a system that implemented dynamic linking by
automatic editing, recompilation, linking and invocation of the
application.  True dynamic linking is often criticized as being too
slow, but it must be several orders of magnitude than the most
well-optimized recompilation scheme.

Algol-68 (or was it Algol-60?) had procedure variables, at least in
the form of call-by-name parameters.  And there are many good uses for
them in C, such as the parameter to the signal() subroutine, which
associates a procedure with a software interrupt.

I could probably go on and on.  Procedure variables are an elegant way
to reduce the complexity of an enormous number of programs.  When I
first saw Ada I noticed two things: 1) the syntax is excessively
verbose and contorted (I really hate the way the verb "IS" is used,
for some reason even I don't understand), and 2) no procedure
variables.


Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar