-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Correct me if I'm wrong, but isn't this more an argument about whether procedures need to be reified as first-class objects "in practice" (as well as just "in effect"), rather than purely about EQV? If a procedure is reified as a closure object, I gather we can easily answer (eqv? x y) as #t if the closure has the same code vector and the same closed-over values (identical, not just same-valued, to allow for mutation, which is trivially #t if there are no closed-over values), and "maybe, can't tell" (spelt #f) if not. But, if I understand correctly, the problem is that smart implementations may optimise closures away through cunning code rearrangements and inlinings, so we may not have an actual closure to look at; and writing a definition of eqv? that depends on such closures would therefore force the implementation to create one. Really, that can go three ways: (a) The implementation doesn't do the optimisation at all and makes a closure in case it's needed, (b) it is smart and avoids making closures if it can prove it won't need them, or (c) it doesn't make closures and just refuses to implement EQV? on procedures. So we're quibbling about whether to make EQV? on procedures demand the creation of closures, based on whether implementations will do (a) or (b), or whether we should just let them do (c), but surely there's other factors to consider that might require first-class closures to be created. Presumably they'll be required if we call things like CONS on procedures, or in general, pass them to procedures imported from separately-compiled libraries. So, don't arguments for not defining EQV? on procedures also extend to not defining CONS on procedures? ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAFQ4oACgkQRgz/WHNxCGpsDgCdHtQimQbrUnYmEykDq/OeDWfU yEoAn3t1tChPEKdM7264m2zwpwn7Py8N =Tom9 -----END PGP SIGNATURE----- _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
