Revision as of 02:40, 29 July 2006

Contents

1 Why we need this

\paragraph{ }
\title{Object Equality and Evaluation Strategy of Lazy Lagnuages}
\author{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.
\paragraph{ }
Using equality test for forcing evaluation is agints design purpose of Haskell.
Hakell 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 \verb|x==x| to \verb|True|.
\paragraph{ }
Functional programming style of persistant data structure tend to
generate shared objects frequently. Functional languages lacking
object equality cannot have full-benefit of sharing
since they cannont optimize equality with object equality.
Functional languages that cannot utilize object equality is
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.
\footnote{There are rare exceptions such as OCaml \texttt{nan}, which is in my opinion a design flaw.}
\paragraph{ }
Therefore, our goal is to develope a 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.

2 Problems in optimizing equality

It is a common idiom to benifit from physical equalitin in C++.

Common idom of C++ copy ctor, assignment and equality:

class C
{
...
C(const C& c)
{
if (*this == &c) return; // the same object!! nothing to do
// do the job if not the same object
}
C& operator = (const C& c)
{
if (*this == &c) return; // the same object!! nothing to do
// do the job if not the same object
}
bool operator == (const C& c)
{
if (*this == &c) return true; // the same object!! nothing to do
// do the job if not the same object
}
...
};

However, haskell being a lazy langauge it has concerns that strict languages would not have.
Let === be the physical equality.
Even though === implies == except for bottom,
there are some situations that we cannot by default optimize equality
with physical equality.
It is because haskell programmer use reflexive equality test as
a common idom for deep evaluation.

2.1 Analyzing haskell insertion sort algorithm

These examples came up doing one of the homework
in CS584 Algorithms (2006 Spring) class at Portland State University,
lectured by Mark P. Jones.
I choose haskell to implement sorting but memory leaked I added the counter.
Thanks to Mark P. Jones for mentioning that
equalities are used for forcing evaluation.