-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/16/2012 09:51 AM, w...@ccs.neu.edu wrote:
> You are speaking as though whether a procedure needs a closure to
> run correctly is a simple binary choice. It is not.
> (define (f m n) (define (g i) (define (h j) (if (= j 0) i (g (- j
> 1)))) (if (< i 0) (if (= i m) h ; must a closure be
> allocated here? #f) (h (- i 1)))) (g n))
> With the R6RS semantics, most calls to f are unlikely to need
> closures, yet the code vector alone is inadequate to distinguish
> proc1 and proc2 defined via
>
> (define proc1 (f -1 -1)) (define proc2 (f -2 -2))
Although these functions have the same code vector,
that code refers to values provided in the arguments
to f -- which is to say, to a closure over f.
I do not see how this example relates to the case we
were talking about, which is specifically a vector of
code which does not refer to values it must get from a
closure.
The proposed rule would not regard proc1 and proc2
as equivalent. (and indeed, *must* not; their
results are different for all positive arguments).
To address the slightly-interesting chunk of the
question, the return values of proc2 on different
positive integers are also procedures that refer
to values they need to get from a nonempty closure.
So the proposed rule would not regard any of them
as equivalent either, regardless of whether a new
(but identical) closure were allocated each time
f got called. Although, in the absence of anything
that can change the closed-over values, the returned
functions over identical closures *do* have effectively
identical semantics, that isn't the specific case
that the proposed rule would obligate implementations
to detect.
It is generally agreed, I think, that implementations
should report functions eqv? equivalent when and only
when the implementations can _prove_ that the functions
do in fact have identical behavior and effects, and
in other cases (whether uncertain of identicality or
certain of difference) to report them not eqv? .
The proposal is that a simple case for implementations
to prove eqv?-ness on functions, and one which can and
ought to be handled by all implementations, is the case
where functions have the same code vector and that code
does not refer to any values held in a closure. (or
perhaps more generally, to any non-eq? values in the
case that your compiler was smart enough to elide the
closure allocation).
I'm stating the obvious here, even though it may sound
dumb, because I'm increasingly concerned that we may in
fact be talking about different things and somehow not
realizing that we are doing so. But I'm baffled
trying to see what issue you might be concerned about
that your example *does* address, so I'm trying to be
very specific about what I'm saying in hopes that the
difference in what we're discussing will be clearer
to you than it is to me.
Bear
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQBGWJAAoJEAOzWkqOibfN7/cH/RvmFNmNw7/+9gQHdi+e/yZy
8dLT84QMTRXQz5/io50hLsRPuNd/bvNkGpltDQAgLdrJx9/M2syfdzBZU1scwTXn
yJW7wX2/xX7x17CBLFbOAZHb0N4DBtEUsFIQmyWFXa90W6+5nYyCBNbHqqeUN1Cl
5h1BMj3mUx5VWaO8pWjAlq3xGLvib6pS+yz0J7TwajSUg/05ORLBT/jUQO0ys6eF
klNFomYzXrPNcSOXpMCCDha9kBm2zAS2sKS5KHkgNLGyHHLcyzV5skMIk+erth3u
IGa2oWpzUrelWkuTFA9q+oeAly+qJCte5mTF4AF/EyQQY/u0dOv3mFEB5qCqRY8=
=bDr8
-----END PGP SIGNATURE-----
_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
