[Nickle] Polymorphic equality and similar mysticism

[Bart Massey]

In message <E1BUZ6D-0004xO-Kn at evo.keithp.com> Keith wrote:
> Around 14 o'clock on May 30, Bart Massey wrote:
> 
> > and insist on subtype compatibility of the arguments: we
> > select the unique equality operator, if any, such that
> > one argument is of matching type and the other is of a
> > supertype.  If there is none, it is a static type error.
> 
> That's either type-based function selection or parametric polymorphism.
> Which is it?  How do we extend that to other functions?
> 
> I don't want a built-in specific kludge here...

Bad news, you've already got one, as I illustrated with the
+ operator. :-) I'm simply proposing that you use that same
operator overloading kludge, albeit with a notionally
infinite set of equality functions, with the == operator,
rather than making its arguments be statically poly and
losing an opportunity to detect errors early.  ML uses
parametric equality, but uses weak types to get away with
it: check out what happens when you say
  fun f(x,y) = (x = y);
at SML/NJ.

Or you can add type-based function selection, aka ad-hoc
polymorphism, to the language.  I guess I don't have a
problem with that, as long as it is controlled in the same
way that it is for builtins: ensure that overloaded
functions are always statically unambiguously decidable
based on types.  The next question with that is whether to
also consider the return type in the disambiguation.  It
would sure be nice to have
   file f = new();
do something sensible, and different from
   string f = new();
but most languages only consider arguments: I'm not sure I
know why.

    Bart