[Grace-core] Grace feedback

[Dan Grossman]

Sure, moving it to the blog makes sense and feel free to quote (with
or without attribution) anything I said.  I don't know of any
definition of equality I'm entirely thrilled with.

--Dan

On Sun, Nov 7, 2010 at 4:52 PM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
>> Seems reasonable, though it might be worth debating the value of SML's
>> polymorphic equality operator compared to EGAL.
>
> sure - but we should feed this onto the blog.
> I'll try to edit it together in the next few days
>
>>  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?
>
> either all return false, or just use object identity.
> I mean if it's closed over mutable variables, its a mutable object,
> so is only == to itself.
>
>> * 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).
>
> yep. We have plans there, whether or not they work will be another questions.
>
>> 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.
>
> yep. We're more likely to go the other way - default to == being
> identity in difficult cases. at least x == x will always be true!
>
> James
>
>> --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
>>>
>>
>
>