[Grace-core] Grace feedback

[James Noble]

> 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
>> 
>