[Grace-core] on equality

[James Noble]

Hi Éric 

> I just saw a recent post that starts with the following quote:

thanks for your message - this is a good question about an important issue!

> "We hold these truths to be self-evident, that all objects are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are sole access to their internal representation"

ah yes, that one :-)

> This reminded me of the (excellent) paper of William Cook (on understanding data abstraction, revisited / onward'09), where he explains his "autognostic principle":
> 
> <quote>
> </quote>
> 
> So, will Grace be true to this pillar of OOP as described by Cook? I mean, not only through object-level encapsulation, but through not supporting a built-in notion of equality. Will it be possible to check if an object is == (low-level) to another?

so: currently, we're not planning to support a built in notion of "equality".
we *are* supporting a built-in notion close to "identity" - 
that will head toward equality only in the case of  "value obejcts "

if you look at this post here: http://gracelang.org/applications/2011/02/07/values-equals-and-hashcodes/

there's a discussion of our plans at that time, based on Henry Baker's EGAL predicate.
We've become slightly less doctrinare since then, but that does outline
the basic plan. 

> The underlying reason (that an object is a set of observations, and that two objects that behave the same should not be distinguishable) is powerful -- but clearly means changing some typical programming idioms...

well yes, except that to ask about equality really means not just "behave the same now"
but "will behave the same in all possible futures".   Object identity satisfies this criterion;
most other kinds of equality do not - and I don't know if we will end up adding in an equals
method later. 

The tension we're faced here (and in other parts of the design) is between purity and utility:
sure it's conceptually clearer *not* to provide equals methods, and *not* to have classes generate types,
and *not* to support operator precedence: but all those choices just end up making more
work for programmers --- especially students --- who are just getting started.

cheers

James 

PS would you mind copying & posting your comments to the blog?

Then I can copy this reply, and it will look like we have some interest - 
which we do have, but it's hidden away on the mailing list!