On Tue, Sep 17, 2024 at 12:27 PM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> On 17/09/2024 18:15, Jordan LeDoux wrote: > > > 1. Are we over-riding *operators* or *operations*? That is, is the user >> saying "this is what happens when you put a + symbol between two Foo >> objects", or "this is what happens when you add two Foo objects together"? >> > > If we allow developers to define arbitrary code which is executed as a > result of an operator, we will always end up allowing the first one. > > > I don't think that's really true. Take the behaviour of comparisons in > your previous RFC: if that RFC had been accepted, the user would have had > no way to make $a < $b and $a > $b have different behaviour, because the > same overload would be called, with the same parameters, in both cases. > > Slightly less strict is requiring groups of operators: the Haskell "num" > typeclass (roughly similar to an interface) requires definitions for all of > "+", "*", "abs", "signum", "fromInteger", and either unary or binary "-". > It also defines the type signatures for each. If this was the only way to > overload the "+" operator, users would have to really go out of their way > to use it to mean something unrelated addition. > > As it happens, Haskell *does* allow arbitrary operator overloads, and in > fact goes to the other extreme and allows entirely new operators to be > invented. The same is true in PostgreSQL - you can implement the > <<//-^+^-//>> operator if you want to. > > I think it's absolutely possible - and desirable - to choose a > philosophical position on that spectrum, and use it to drive design > decisions. The choice of "__add" vs "operator+" is one such decision. > > > Ah, I see. I suppose I never really entertained an idea like this because in my mind it can't even handle non-trivial math, let alone the sorts of things that people might want to use overloads for. Once you get past arithmetic with real numbers into almost any other kind of math, which operators are meaningful, and what they mean exactly, begins to depend a lot on context. This is why I felt like even if we were limiting the use cases to math projects, things like commutativity should not necessarily be enforced. The line `$a + $b` and `$b + $a` are SUPPOSED to give different results for certain types of math objects, for instance. The line `$a - $b` and `$b - $a` more obviously give different results to most people, because subtraction is not commutative even for real numbers. My personal opinion is that the RFC should not assume the overloads are used in a particular domain (like real number arithmetic), and thus should not attempt to enforce these kinds of behaviors. But, opinions like this are actually what I was hoping to receive from this thread. This could be the way forward that voters are more interested in, even if it wouldn't be my own first preference as it will be highly limiting to the applicable domains. > > The approach I plan to use for this question has a name: Polymorphic > Handler Resolution. The overload that is executed will be decided by the > following series of decisions: > > 1. Are both of the operands objects? If not, use the overload on the one > that is. (NOTE: if neither are objects, the new code will be bypassed > entirely, so I do not need to handle this case) > 2. If they are both objects, are they both instances of the same class? If > they are, use the overload of the one on the left. > 3. If they are not objects of the same class, is one of them a direct > descendant of the other? If so, use the overload of the descendant. > 4. If neither of them are direct descendants of the other, use the > overload of the object on the left. Does it produce a type error because it > does not accept objects of the type in the other position? Return the error > and abort instead of re-trying by using the overload on the right. > > > This is option (g) in my list, with the additional "prefer sub-classes" > rule (step 3), which I agree would be a good addition. > > As noted, it doesn't provide symmetry, because step 4 depends on the order > in the source code. Option (c) is the same algorithm without step 4, so > guarantees that $a + $b and $b + $a will always call the same method. > > Options (d), (e), and (f) each add an extra step: one operand can signal > "I don't know" and the other operand gets a chance to answer. They're > essentially ways to "partially implement" an operator. > > Options (a) and (b) perform the same kind of polymorphic resolution on > *both* operands, which is how many languages work for functions and/or > methods already. > > > Reading the C# spec, if there is more than one candidate overload which is > equally specific, an error is raised. I guess you could do the same even > with one implementation per class, by replacing step 4 in your algorithm: > > > 4. If neither of them are direct descendants of the other, and only one > implements the operator, use it. > > 5. If neither of them are direct descendants of the other, and both > implement the operator, throw an error. > > Let's call that option (h) :) > > > By the way, searching online for the phrase "Polymorphic Handler > Resolution" finds no results other than you saying it is the name for this > algorithm. > > > Hmmm, I will see if I can find where I came across the term in my original research then. I did about 4 months of research for my RFC, but that was several years ago at this point, so I might be mistaken. So I understand here that you're looking for commutativity in *which overload is actually called*, even if it doesn't create commutativity in the result of the operation. That the *executed overload* should be the same no matter the order of the operands. This was something I also was interested in, but I could not find a solution I was happy with. All of the things you have detailed here have tradeoffs that I'm unsure about. This is an open question of design that I feel requires more input and more voices from others who are interested, because I don't feel like any of these approaches (including the one that I went with) are better, they are just different. > This is similar to what I originally designed, and I actually moved to an > enum based on feedback. The argument was something like `$isReversed` or > `$left` or so on is somewhat ambiguous, while the enum makes it extremely > explicit. > > > Ah, fair enough. Explicitness vs conciseness is always a trade-off. My > thinking was that the "reversed" form would be far more rarely called than > the "normal" form; but that depends a lot on which resolution algorithm is > used. > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > It would also depend on whether it is used with scalars. For instance, `$numObj - 5` and `5 - $numObj`. For both of these, you want to call the overload on `$numObj`, because it's the only avenue that won't result in a fatal error (assuming that the overload knows how to work with int values). The case of an object with an overload being used with an operand that is a non-object will most likely result in reversed calls quite frequently. This will be a prominent issue for some use cases (like arbitrary precision math), and an almost non-existent issue for other use cases (like currency or time). Jordan
