On Thursday 19 July 2007 01:20:48 you wrote:
> Sure!  I suppose "SML-style equality" can be understood to include
> various things:
>
>    (1) an equality predicate that tests for physical equality at mutable
>        types and structural equality at immutable types.
>
>          SOME 3 = SOME 3
>          => true
>
>          SOME (ref 3) = SOME (ref 3)
>          => false

I forgot about this. I prefer OCaml's approach (physical and structural) 
actually. I use physical equality a lot as an optimization and I think that 
makes sense in an impure FPL.

>    (2) a compile-time error if you try to use equality at a type for
>        which it's not defined (an abstract or functional type)
>
>          - op o = op o;;
>          stdIn:4.1-4.12 Error: operator and operand don't agree
>          [equality type required]

This is what I was thinking of.

>    (3) a means to write functions that are polymorphic over equality
>        types:
>
>          - fn x => x = x;;
>          val it = fn : ''a -> bool

and this.

> With `deriving' you get (1) and (2).  You can simulate (3) using
> functors if you squint a bit.  In all cases you have to be explicit
> about types, i.e. you have to write
>
>     Eq.eq<int ref option> (Some (ref 3)) (Some (ref 3))
>
> rather than (say)
>
>     Eq.eq (Some (ref 3)) (Some (ref 3))
>
> Specifying types is perhaps a bit of a nuisance, but to make up for it
> you get a bit more flexibility: equality can be customized at
> particular types.

Ah, I did not realise you had to add type annotations everywhere by hand. I 
was rather hoping you could spot existing incorrect applications like:

  lazy 3 = lazy 3

This is simply because I want to apply it to an existing code base.

> I hope this helps a bit.  The documentation on the website gives more
> examples.  There'll also be a paper out soon which should explain
> things in more depth.

That's great, thank you. This is a beautiful piece of work but I think what 
I'm after requires a different approach.

I'm not quite sure how it could be done, short of altering the type system in 
the OCaml compiler. Maybe by adding a phantom type variable to every type, 
but I think that would require higher-order types:

  val ( = ) : [> `eq] 'a -> [> `eq] 'a -> bool

F# takes the Haskell approach of carrying an equality function in a dictionary 
with every type. That is a burden but it is probably a preferable solution 
overall (you just override the equality type when necessary). Some 
inconsistencies remain though, as you don't want to create a new list type 
every time you use a different comparison function, so Set assumes the 
equality from the dictionary whereas List.sort still uses an explicitly 
specified total order.

I can't believe how often I fall for this stupid bug. Even my first attempt at 
writing a GUI Sudoku solver for the OCaml Journal made the classic mistake of 
applying = to a pair of Maps. It would be very nice indeed if OCaml would 
catch such errors...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e