chased@rbbb.Eng.Sun.COM (David Chase) (05/22/91)
In article <9105211642.AA01692@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writes: >By the way, here is another situation where the Report seems >a bit ambiguous about static versus dynamic scopes: > > MODULE M2 EXPORT Main; > > PROCEDURE MemeChose(n: INTEGER; p: PROCEDURE():INTEGER): BOOLEAN = > > PROCEDURE G(): INTEGER = > BEGIN RETURN n END G; > ... >The question is whether all instances of G are the same procedural >value, i.e. whether the "environment" component of a procedure value >is a static scope or a dynamic scope. To further confound the issue, >the Report calls G a procedure *constant*... No ambiguity at all; I recall seeing the words specifying that each instance of G was distinct, and being very unhappy about the fact that this would require creation of a distinct value even in those cases where it was not necessary. "Procedures are equal if they agree as closures; that is, if they refer to the same procedure body and environment." (See "EXPRESSIONS.Relations, paragraph 2.) I think it's a stupid rule, but it's clearly stated. (Why do I think it is stupid? Because use of local procedures that inherit no bindings from their lexical ancestor is made more expensive, so that an extremely rare equality test is made well-defined.) G is certainly a constant, too -- it's just a different constant in different environments (same name, different value). Note that they did not call it a "literal". David Chase Sun
stolfi (Jorge Stolfi) (05/22/91)
> [David Chase, quoting:] "Procedures are equal if they agree as > closures; that is, if they refer to the same procedure body and > environment." (See "EXPRESSIONS.Relations, paragraph 2.) Yes, I am aware of this passage. But the "environment" of a procedure value is defined as "the scope with respect to which the variable names in the body will be interpreted" (page 9). The question is whether "scope" here means "static scope" or "dynamic scope". Reasoning backwards, one could argue that since G is supposed to be a "constant", its environment must be the static scope. In fact, I don't think the report says what the value of F(FALSE, NoOp) should be, given the following declarations: PROCEDURE F(arg: BOOLEAN; p: PROCEDURE(x: INTEGER)): INTEGER = VAR local: INTEGER; PROCEDURE G(x: INTEGER) = BEGIN local := x END G; BEGIN IF arg THEN local := 777; p(999); RETURN local ELSE RETURN F(NOT arg, G) END END F; PROCEDURE NoOp(x: INTEGER) = BEGIN END NoOp; I don't think it says anywhere in the report that the call to p(999) must modify the previous instance of "local", as opposed to the current one. I think the latter would be consistent with interpreting "environment" as "static scope", and it could be the semantics of a naive implementation of local procedures (e.g. using "display" registers a la Algol 60). Please note that I am only being a devil's advocate here. Surely, the dynamic interpretation is more natural and useful than the static one. (Perhaps it would have been even more correct to define the environment as the set of all variables *actually referenced* by the body. However, I suspect that this definition would be somewhat harder to implement than the present one.) > G is certainly a constant, too -- it's just a different constant > in different environments (same name, different value). As the motto goes, "variables won't; constants aren't"... 8-) I guess the problem is that some declarations (e.g. branded TYPE) must interpreted statically, whereas others (VAR) must interpreted dynamically. CONST declarations can be interpreted either way, but since the language forces their values to be truly constant, most compilers will probably opt for the static interpretation. So, it is not immediately obvious whether local procedure declarations are static or dynamic. Jorge Stolfi DEC Systems Research Center