Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!stolfi
From: stolfi (Jorge Stolfi)
Newsgroups: comp.lang.modula3
Subject: Re: procedure value ambiguity
Message-ID: <9105212008.AA08530@jumbo.pa.dec.com>
Date: 21 May 91 20:08:12 GMT
Lines: 62
In-Reply-To: Message of 21 May 91 18:10:08 GMT
    from chased@rbbb.Eng.Sun.COM (David Chase)
    <13720@exodus.Eng.Sun.COM>
To: m3
Cc: chased@rbbb.Eng.Sun.COM (David Chase)
X-Folder-Carbon: sent


    > [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