[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] Scheme-reports Digest, Vol 41, Issue 4
- To: scheme-reports@x
- Subject: [Scheme-reports] Scheme-reports Digest, Vol 41, Issue 4
- From: Gerald Jay Sussman <gjs@x>
- Date: Tue, 4 Jun 2013 18:50:15 -0400
- Cc: gjs@x
- In-reply-to: <mailman.1.1370361601.3040.scheme-reports@scheme-reports.org> (scheme-reports-request@scheme-reports.org)
I really like the old R5RS semantics for procedure equivalence.
Scheme started with the assumption that procedures produced by
evaluating lambda expressions were objects with identity. Indeed we
naively expected procedures to model Hewitt's actors. As a
consequence of that underlying assumption we didn't think of actually
specifying the behavior of EQ? on procedures.
And from the point of view of the semantics, consider the expression
(let ((p <anything>)) (eq? p p)). We thought it was obvious that
(eq? p p) is true independent of the kind of object p refers to.
Indeed, if EQ? is intended to be the finest possible equivalence
relation on Scheme objects, then it better be reflexive, symmetric,
and transitive, to be an equivalence relation at all. Any other
choice yields a much more complex semantic interpretation.
On the other hand, we also recognized that numbers were special: that
two floats or two bignums would not be sensible to compare with EQ?.
So we just didn't think of numbers as objects -- they were something
else. Of course, it is usually not appropriate to compare two
(inexact) floats for equality at all!
Because of the assumption that procedures are objects with identity, I
have lots of code that uses EQ? on procedure objects. For example, I
often put "sticky notes" on a procedure that gives additional
information about the procedure, using an associative mechanism that
uses EQ? and weak tables. My programs can examine the sticky notes on
a procedure to make it "referentially translucent" and thus help do
some reasoning about it. So a change to the specification of EQ?
will make lots of work for me. I have to chase down exactly where it
matters and where it doesn't. (Remember that MEMQ, ASSQ, DELQ, etc.
all depend on EQ?.)
I feel bad about the idea of complicating the semantics of a language
to make compiler optimizations easier to make. But I am willing to
accept Will Clinger's compromise and do the work required to fix my
code, if it improves the cohesiveness of the community. However, I
would not be happy with a result that makes it impossible for me to
continue to use procedures as light-weight objects that can hold a
sticky note,
Gerald Jay Sussman
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports