Re: MMD thoughts 2008
HaloO, Buddha Buck wrote: Is this right? (E,D,D) to (A,C,C) is (4,1,1), with a L1 metric of 6. (E,D,D) to (D,A,A) is (1,3,3) with an L1 metric of 7. Are you sure (E,D,D) would bind to (D,A,A)? Oh, shit. I fail with the simplest of mathematics. Indeed (E,D,D) binds to (D,A,A). The problem I want to point out remains, though. The two Ds are handled as As where a C treatment was available. The point is that metric MMD here either fails on E or D to be most specific. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: MMD thoughts 2008
Sorry, you're not following me at all. I'll try again later. TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: HaloO, John M. Dlugosz wrote: OK, why would someone create those forms in the first place? I would think they grow like that historically. A five steps long subtyping chain is not particularly extraordinary. Note that multi entries live outside of classes and their single dispatch. The subtyping relationship could mean either value subset (e.g. integer passed to code that can handle reals) or polymorphic "isa" objects. The implementation should treat the E correctly because of virtual functions on E, even though the code was written for an A. Yes, but code that specifies to get an A sanely only uses functionality covered by that requirement. E <: A of course means that the A interface works on an E. But a multi method target should be the most specific choice for *all* parameters. Only that guarantees that all relationships amongst the involved types are taken into account up to a *deterministic* level of specificity. So why write different forms with =related= classes? Different forms? I would define operators with the same name around unrelated classes, so I can use that operator with things that don't already know what to do. If I understand what you say, then you mean homogeneous multis. These can be implemented with single dispatch on the invocant and generic type enforcement for the other parameters. But MMD is about the heterogeneous case! BTW, the types that "already know what to do" must be implemented with the same features as all the others. There are no magic built-ins. So why are we focusing on the pathalogical cases? That's like saying we should not support division because you could divide by zero. But we throw an exception just as with a faulty dispatch. Rather, what is the common typical use? For the bad stuff, "don't do that" and "do this instead". I think the MMD should work well and be tuned for the areas in which it ought to be used, and the above problem analyzed to see what the programmer was really trying to accomplish. You want a runtime analysis what the programmers might have meant? So Perl 6 requires AI? Regards, TSa.
Re: MMD thoughts 2008
Sorry to reply to the wrong comment, but I lost the original thread in my mail archives and didn't notice this until now. On Tue, May 6, 2008 at 1:54 PM, John M. Dlugosz <[EMAIL PROTECTED]> wrote: > TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: > > > > > The fundamental flaw of metric mmd is that it trades degrees of > > specificity. Consider the subtype chain E <: D <: C <: B <: A > > where the rule is that having an E it is better handled by a > > method dealing with a D than one dealing with an A. The same > > is the case for having a D being better handled by a C than an > > A method. Now consider a multi with the two signatures :(A,C,C) > > and :(D,A,A) and a call with (E,D,D) that goes to :(D,A,A) since > > 7 < 8. But note that it handles the two Ds as As instead of Cs > > as in single dispatch. Is this right? (E,D,D) to (A,C,C) is (4,1,1), with a L1 metric of 6. (E,D,D) to (D,A,A) is (1,3,3) with an L1 metric of 7. Are you sure (E,D,D) would bind to (D,A,A)?
Re: MMD thoughts 2008
HaloO, John M. Dlugosz wrote: OK, why would someone create those forms in the first place? I would think they grow like that historically. A five steps long subtyping chain is not particularly extraordinary. Note that multi entries live outside of classes and their single dispatch. The subtyping relationship could mean either value subset (e.g. integer passed to code that can handle reals) or polymorphic "isa" objects. The implementation should treat the E correctly because of virtual functions on E, even though the code was written for an A. Yes, but code that specifies to get an A sanely only uses functionality covered by that requirement. E <: A of course means that the A interface works on an E. But a multi method target should be the most specific choice for *all* parameters. Only that guarantees that all relationships amongst the involved types are taken into account up to a *deterministic* level of specificity. So why write different forms with =related= classes? Different forms? I would define operators with the same name around unrelated classes, so I can use that operator with things that don't already know what to do. If I understand what you say, then you mean homogeneous multis. These can be implemented with single dispatch on the invocant and generic type enforcement for the other parameters. But MMD is about the heterogeneous case! BTW, the types that "already know what to do" must be implemented with the same features as all the others. There are no magic built-ins. So why are we focusing on the pathalogical cases? That's like saying we should not support division because you could divide by zero. But we throw an exception just as with a faulty dispatch. Rather, what is the common typical use? For the bad stuff, "don't do that" and "do this instead". I think the MMD should work well and be tuned for the areas in which it ought to be used, and the above problem analyzed to see what the programmer was really trying to accomplish. You want a runtime analysis what the programmers might have meant? So Perl 6 requires AI? Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
MMD thoughts 2008
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: The fundamental flaw of metric mmd is that it trades degrees of specificity. Consider the subtype chain E <: D <: C <: B <: A where the rule is that having an E it is better handled by a method dealing with a D than one dealing with an A. The same is the case for having a D being better handled by a C than an A method. Now consider a multi with the two signatures :(A,C,C) and :(D,A,A) and a call with (E,D,D) that goes to :(D,A,A) since 7 < 8. But note that it handles the two Ds as As instead of Cs as in single dispatch. OK, why would someone create those forms in the first place? The subtyping relationship could mean either value subset (e.g. integer passed to code that can handle reals) or polymorphic "isa" objects. The implementation should treat the E correctly because of virtual functions on E, even though the code was written for an A. So why write different forms with =related= classes? I would define operators with the same name around unrelated classes, so I can use that operator with things that don't already know what to do. So why are we focusing on the pathalogical cases? That's like saying we should not support division because you could divide by zero. Rather, what is the common typical use? For the bad stuff, "don't do that" and "do this instead". I think the MMD should work well and be tuned for the areas in which it ought to be used, and the above problem analyzed to see what the programmer was really trying to accomplish. Maybe for special tuning in hacked-up (as opposed to nicely refactored code) we need something like submethods, that handle the exact case and don't get in the way of other distances. Maybe some of this should be done with generics rather than MMD. For example, I don't need to define something on a wide variety of number-like types individually, I'll use generic types to specify the minimal properties of the kind of type it applies to, and that the arguments match. So my MMD is between two forms: "anything that is integral in nature" and "anything that is a type of Vehicle", without any analysis concerning whether a Bus is more like a generic Vehicle than a BCD is like an abstract integer concept. --John
