[Grace-core] Equality of method names

[Personal]

Following up, somewhat belatedly, on the discussion that started while we were commenting on Tim's smallstep Operational semantics, I wanted to offer some further thoughts on when two method names are the same or different.

Now that variable-arity methods are gone, we can conveniently name methods by putting positive integers inside the brackets.  So, for example, max(2) or assert(1)shouldBe(1) or increment are method names with one, two and zero parameter lists of lengths 2, (1, 1), and ( ).

So the question now arrises whether, say, assert(1)shouldBe(1) and assert(2)shouldBe(1) are the same or different.  Pragmatically, "the same" means that requests of one can cause an execution of a method declared using the other.

I've argued, based on experience with Emerald, that we should treat them as different.  This has beneficial theoretical implications, because it means that all the lubs and glbs in the type lattice exist.  It also makes it easier to fix up software engineering mistakes by applying refactorings like introduce parameter object.  Kim has argued that treating them as different is a bad idea, primarily, I think, because it may be harder to produce a good error message if a student accidentally uses the wrong number of arguments.  (I'm not convinced that this is the case, but I do agree that the implementor may have to work harder to produce the good error message.) If they are different, then, for example, declaring one of them in an object that inherits the other is not a problem. 

The other position that one can logically take is the opposite one: the two names are the same, and that the arities of the argument lists don't have any say in determining method name identity; the only thing that matters is the method name itself, and the positions of the argument lists, and, perhaps, the number of argument lists.   If the names are the same, it seems more reasonable to introduce restrictions on what sort of overriding declarations might be allowed in a dialect.

If the names are the same, then a request of m(2) might be "caught" by a method m(1) and by a method m(2).  In this case, one or other of these requests might fail, with a wrong number of arguments error; this is no different in principle, it seems to me, from having two method implementations with different parameter types. I can see that it might also be possible to make both succeed, using some form of pattern-matching of the parameter and the argument objects.
I don't know enough about pattern-matching to be able to say how this might work, but the idea is that if the method takes a parameter of type Point, and the request has two arguments of type Number, then we might be able to match one against the other on the basis of the same sort of rule that allows a Point object to be pattern-matched against an (x, y) pair.

In our discussions, though, I thought that I heard a third position, in which the names were neither different nor the same, but some sort of hybrid — even though they were different, they should be treated as the same under some circumstances, such as when a declaration should be treated as an overriding.  I don't really understand this position, and therefore don't really understand the arguments for adopting it.

Am I hallucinating?   Do any of us advocate for such a hybrid position?  If so, could you please explain it to me, and argue for why it is the right position?

Andrew P Black