[Nickle] Polymorphic equality and similar mysticism

Bart Massey bart at cs.pdx.edu
Sun May 30 14:23:33 PDT 2004


First, consider

  int plus_ii(int x, int y) { return x + y; }
  string plus_ss(string x, string y) { return x + y; }
  poly plus_si(string x, int y) { return x + y; }
  poly plus_pp(poly x, poly y) { return x + y; }

plus_ii and plus_ss are clearly fine, and work fine.
plus_si fails with a static type error, as expected/desired.
plus_pp does runtime type checking, as desired.

(Now consider

  poly call_plus_pp(int x, string y) { return plus_pp(x, y);  }
  
It could be statically decided that this will never work,
given the definition of plus_pp(), but we choose not to do
that---seems fine, but worth mentioning.)

The current Nickle == operator denotes a polymorphic
function
  bool equal(poly, poly)
that is guaranteed to return false anytime its arguments are
of different type.  Seems harmless, but I claim that
  bool equal_si(string x, int y) { return x == y; }
should probably fail to static typecheck---this is almost
certainly a programmer error.  In other words, I propose
that we notionally replace the current polymorphic equal()
with a massively overloaded equal()
  bool equal(string x, string y)
  bool equal(int x, int y)
  ...
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.

This doesn't seem hard to implement given the current
machinery, and IMHO would be nice.  In addition to catching
errors earlier, it would give the compiler the opportunity
to select a more efficient comparison statically.  Am I
missing something?

	Bart



More information about the Nickle mailing list