[Grace-core] Grace feedback

[Dan Grossman]

Seems reasonable, though it might be worth debating the value of SML's
polymorphic equality operator compared to EGAL.  A couple particular
dragons:

* In SML, one cannot use == with closures. At quick skim, Baker
specifically argues against this (i.e., allowing such comparisons),
but it's not clear it's worth the trouble.  In a dynamically typed
world, one could have comparison of closures always return false
perhaps.  Is supporting  closure- comparison important?

* In SML, one cannot use == to compare floating-point numbers.  This
is a pretty good idea, since:
   (a) it's usually a bad idea to compare floats for equality
   (b) implementing == correctly is a pain because the agreed-upon
floating-point standards require that == /not/ be bit-equality (e.g.,
-0==+0).

Alas, SML ended up having to distinguish type variables (generic
parameters) that can be compared with == from those that cannot,
something you should probably avoid.  It's not clear how to do that.
OCaml just gave up and used structural equality even for mutable
structures, which you're definitely trying to avoid.

--Dan

On Sat, Nov 6, 2010 at 11:25 PM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
> Hi Dan
>
>> * yes, please add me to the lower-traffic "announce list" and inform
>> me when significant content goes up on the website, though I suspect
>> the latter will be subsumed by the former.
>
> we shall see: we're feeling out way with this.
>
>> * sure, I'd be happy to send Marty a message once there's more content
>> up and convince him that this is something he should be interested in.
>
> sounds good!
>
>> * then there's the issue of my integer_set ADT example....
>
> this is interesting - I've been thinking about it since we talked
> at SPLASH (now hopefully the rest of us will too)
>
>>  As another example, I'd like the
>> language to have a sane way to write an equals method.
>
> so our current plans there is that equals (and hash-code) will be
> defined automatically following Henry Baker's EGAL predicate.
> (http://home.pipeline.com/~hbaker1/ObjectIdentity.html).  If you really
> want to write a method that means "instantaneously has the same
> contents as another collection" then you can - but the aim is that
> the language and its core libraries won't rely on such user-defined
> predicates - so if you want one, it can be rather more specialised
> than a Java equals method.
>
> We think the main change from standard Java practice
> will be having to use immutable lists or tuples instead of mutable
> collections as *keys* in hash tables, and in some cases, substituting
> those hash tables for sets.
>
> cheers
>
> James
>