[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