Editing Physical equality (section)

== Why we need this ==

By Ahn, Ki Yung

Lazy languages like Haskell have a good excuse for
not having object equality (or physical equality):
the equality test is a hack for forcing evaluation.
We can make use of object equality in Haskell if we can provide a resonable
alternative for forcing evaluation; it would be even better if we can
automatially decide when to evaluate. Therefore, we suggest we should
search for a evaluation strategy that will dismiss the use of equality
test as forcing evaluation.

Using equality test for forcing evaluation is against the philosophy of Haskell.
Haskell has only one equality operator unlike Unlike Scheme or ML,
which is to be simple and clean. But we have assigned strange operational
semantics on equality. This is also problematic for partial evaluation;
we cannot replace ''x==x'' with ''True''.

The functional programming style of persistent data structures tend to
generate shared objects frequently. Functional languages lacking
object equality cannot have the full-benefit of sharing
since they cannot optimize equality with object equality.
Functional languages that cannot use object equality are
giving up the optimization opportunity on the best-fitting domain.
It is a common idiom to check object equality before structural equality.
Object equality implies structural equality,
unless we are dealing with non-deterministic objects.
(There are rare exceptions such as OCaml ''nan'', which is in my opinion a design flaw)

Therefore, our goal is to develop an evaluation strategy that intelligently
forces evaluation when it is sure that forcing evaluation will not take too
long and save space as well. For this we would need both static analysis and
evaluation strategy at runtime.
When we rely less on operational semantics of equality,
we can have better optimization opportunities
such as using object equality in equality tests.