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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,799e6e37c90ca633 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Future Ada language revisions? Date: 1998/10/22 Message-ID: #1/1 X-Deja-AN: 403747203 Sender: bobduff@world.std.com (Robert A Duff) References: <70lquh$mrp@netline.jpl.nasa.gov> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1998-10-22T00:00:00+00:00 List-Id: vsnyder@vanpcjpl.nasa.gov (Van Snyder) writes: > The reason that internal procedures can't be used for actual arguments seems > to revolve around the possibility that their "addresses" might be copied, > because when they appear as formal arguments they're "access to procedure" > with no additional restrictions. Right? Right. > Could we have another annotation for access formal arguments that prohibits > using them for anything other than actual arguments, and dereferencing them? > Say, "limited"? The Ada 9X team proposed exactly that. As an alternative, we also proposed a set of rules that would allow copying, but not to a more-global place. Both of these proposals were rejected, primarily on the grounds that they are hard to implement if the compiler uses a "display" to implement a procedure's environment, rather than a "static link". I think it was a mistake. I liked the "limited" idea best. It matches Pascal's semantics for passing procedures as parameters. This is the only case I can think of where Ada is less powerful than Pascal. >...This would loosen up the restrictions on actual arguments > that are procedures substantially. Well, you would normally use one or the other. There are really two separate features here: 1. Call-backs. The caller passes in a procedure that lives pretty-much forever, and the callee can save it away in some global data structure. This is supported by Ada 95. It is often used in interfacing to things like windowing systems. 2. Downward closures. The caller passes in a possibly-local procedure, and the caller is *not* allowed to save it in a global data structure. This is not directly supported by Ada 95, although there are two workarounds: (1) pass the procedure to a generic, and (2) pass a pointer to a tagged type, where you have overridden the "do it" operation, and the tagged type contains the procedure's environment. Note that C supports 1, but not 2 (since C doesn't support nesting at all, much less passing nested procedures as parameters). Note also that gcc supports both 1 and 2. Interestingly, gcc uses neither of the approaches I mentioned (displays or static links). Instead, it uses a "trampoline" mechanism, which involves writing machine code into the stack, and passing around pointers to that machine code. Self-modifying code! Also the gcc extension is unsafe, in that it allows dangling pointers-to-functions. The two Ada 9X proposals I mentioned above were safe -- the "limited" proposal prevented copying of pointers-to-procedures at compile time, and the other one checked at run time that any copying could not create dangling pointers. - Bob -- Change robert to bob to get my real email address. Sorry.