Next to the == operator, which defines equality through identity, we should
introduce an
operator = which defines structural equality (cfr. eq? versus equal? in
Scheme). e.g. [2,3] is not
== to another [2,3] table, but [2,3] should be = to [2,3]
== is already implemented and falls back on Java’s equals method, which in
turn falls back on
Java’s == operator. Structural equality implies deep equality. For ‘leaf’
objects like symbols,
numbers, etc., deep equality is identity. For ‘compound’ objects like
tables, all elements of the
tables must be deep equal.
This raises the question whether objects should support = and what it means for
them. Objects
can be considered as maps from symbols to values, so two objects are equal if
they map the
same symbols to equal values. The problem here is that performing deep equality
like this is
both A) very costly B) dangerous because it is a graph-traversal (have to keep
track of already
visited objects? even for tables, consider: t[1] := t)
Maybe in a first stage we should simply consider implementing = only on tables
to do a deep
comparison.
Original issue reported on code.google.com by tvcut...@gmail.com on 16 Sep 2008 at 2:04
Original issue reported on code.google.com by
tvcut...@gmail.comon 16 Sep 2008 at 2:04