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!ncis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!decwrl!purdue!rjh From: rjh@cs.purdue.EDU (Bob Hathaway) Newsgroups: comp.lang.ada Subject: Re: procedure types Message-ID: <5865@medusa.cs.purdue.edu> Date: 19 Jan 89 19:55:16 GMT References: <890119102705.20e0039e@elcc.epfl.ch> <4140@hubcap.UUCP> Sender: news@cs.purdue.EDU Reply-To: rjh@cs.purdue.edu (Bob Hathaway) Organization: Department of Computer Science, Purdue University List-Id: > My idea was that if for example a procedure referenced an externally > defined variable X, then that and all other externally referenced > objects should form part of the procedure's specification. Then if > the procedure was called in a context which did not include X, of > the type that X was expected to be, then an error similar to a > "missing parameter" error would occur. Since a specification now > includes all possible interactions between a procedure and its context, > we should then be free to pass procedures around without restriction. Typically, a procedure's environment is determined statically from its declared environment and not dynamically at runtime. There is also binding of other objects X such as functions and packages, etc. Your approach appears to use dynamic binding of the procedural variables environment; do you think this approach is better than the usual static binding rules of Ada objects? > Other advantages would accrue in that during debugging and maintenance, > it is frequently difficult to determine which global variables a > procedure is referencing. By requiring that a shield exist by default, > and providing a facility for poking holes in that shield, the compiler > can provide a guarantee that the list of externally referenced objects > is valid, eliminating the fact that one can never really be certain > that the documentation regarding what this procedure allegedly accesses > bears any relationship to the procedure's actual behavior. I agree entirely. In Modula, this can be accomplished by encapsulating a procedure in a local module and exporting the procedure. The import/export mechanism can be used to provide explicit access to global variables. But this is a clumsy approach and a primitive mechanism would be better. Bob Hathaway rjh@purdue.edu