RE: [Sml-implementers] extensions to SML

[Stephen W. <sw...@in...>]

> I would eliminate equality polymorphism entirely.

I have several objections to dropping polymorphic equality.

* Loss of overloaded = on ints, words, chars, etc.
* Loss of performance.
* Excessive code to write, and decrease in maintainability.

The first point is obvious, but minor.  The next two points are neither obvious
nor minor, so I will explain.  Suppose I want to implement equality on the
following datatype.

datatype t = A | B | C

If there is no polymorphic equality, I have to write

val equals: t * t -> bool =
  fn (A, A) => true
   | (B, B) => true
   | (C, C) => true
   | _ => false

On the other hand, with polymorphic equality, I can write

val equals: t * t -> bool = op =

For large enumerations (I can think of one in the MLton sources with over 150
variants), the first approach is a lot of code.  It is also error prone, since I
have to remember to add a new case whenever I add a variant.  Finally, I don't
think any SML compiler will do the right thing for the first approach, which is
to implement equals as a single integer comparison.  I know that for the second,
MLton will use a single comparison, and I hope that other compilers do too.

Similar arguments apply even when there are non-value carrying variants.