Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.lang.modula3
Subject: Re: procedure value ambiguity
Message-ID: <13720@exodus.Eng.Sun.COM>
Date: 21 May 91 18:10:08 GMT
References: <9105211642.AA01692@jumbo.pa.dec.com>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 39

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