Jeffrey Mark Siskind <qobi@ai.emba.uvm.edu> wrote in article
<xoh207phlrq.fsf@ai.emba.uvm.edu>...
> 1. We all agree that that EQUAL? should not be defined on procedures.
Because
> EQUAL? is defined extensionally and equality of procedures is
undecidable.
> But it is nonetheless *useful* to compare *intensions* of procedures
(i.e.
> representations of procedures, in other words code pointers) for
equality.
Let me clarify. Pointer-equality is a useful thing -- I didn't contest
that. I claimed
that the ability to write code that specifies that a value (be it a
cons-cell, closure, or integer)
is immutable is an important thing to have, be it for program reasoning
purposes or
for optimization.
As long as Pointer-equality is defined as in languages like O'Caml,
it disrupts neither reasoning nor optimization, simply because the compiler
is
free to return "false" even if two references appear to be pointing to the
same object
at the source-level (e.g., "let x = (a,b) in x == x end" may evaluate to
true or false,
depending upon the implementation.)
> 2. Scheme doesn't get this quite right either. In fact, no language that
I
> know of gets this right.
Agreed. Non-deterministic semantics aside, a general conservative pointer
equality predicate (in the style of O'Caml but extended to cover all
values)
is generally useful. A hash function or in general, an order on all values
would also be useful, but requires considerably more support in the
presence
of a copying garbage collector.
It's truly ironic that Scheme requires a non-deterministic semantics in
order
to deal with the argument evalution order issue, but doesn't extend eq to
closures.
-Greg
|