On Fri, Jul 08, 2005 at 11:57:04 -0700, Larry Wall wrote: > On Fri, Jul 08, 2005 at 02:14:27PM +0000, Luke Palmer wrote: > : Anyway, I think that once we start diving inside expressions to > : measure their specificity, we've gotten too complex to be predictable. > > I would like to point out that for mere mortals, *any* MMD is already too > complex to be predictable. Some people can't even predict SMD. :-/ > > Regardless of the MMD policy (or range of policies) we allow/enforce, > I think we need to consider what the naive user is to do in the face > of the (to them) black box of MMD. I wonder if there's some way to > annotate a call to say exactly which routine you expect it to call, and > then if MMD dispatches elsewhere, you get some kind of a warning that > tells you exactly why it chose the other routine over your routine. > It doesn't have to dump the whole MMD decision tree on them, but > merely say something like "Argument $foo picked a constrained type > over an unconstrained type". Or "Argument $bark picked Dog with > distance 1 over Mammal with distance 2". Or "Argument $bark picked > 'Dog where...' with distance 1-ε over Dog with distance 1". > > Unless we can feed more specific information to the naive user > in an easily digestible form, I'm still inclined to say that *any* > constraint just subtracts "epsilon" from the distance, and if you don't > write your constraints to be mutually exclusive within a single file, > and you depend on the dispatch order to distinguish, it's erroneous.
Epsilons are a bit like handwaiving, in the sense that it's not as clear cut. I'd rather they be unexposed for the most part (see below for exception), but that in general different sets of contraints are in a total different ballpark of weighting. I think any ambiguity that is not explicitly resolved from the caller (by means of disambiguation syntax that is like the annotation syntax, whatever it may be) should be an error (preferably compile time, if the type of the value we're dispatching on is inferred or declared). > (We could still subtract addtional values of epsilon for later files > to make Yuval happy--or at least less unhappy...) ;-) I actually think that definition order is now irrelevant, with the exact semantics I proposed. Rob Kinyon had a strong argument (in #perl6) that anything that depends on load order is bound to make someone's head hurt. He has a point. > Then Yuval's overriding files can be distance 0.98, 0.97, 0.96, etc. > An epsilon of .01 should be small enough for anyone. (Or at least > any engineer.) Hmm... that's a useful hack, but I don't think it's much more than a last-resort type hack. Either way, I will always place line long comments on exactly why i'm adding that value. I'd rather have my code document itself, much like functional pattern matching. > Of course, if we make the MMD rules sufficiently complicated, we'll > just have to make the warning spit out a spreadsheet to show the > calculations. Then we hide all that behind an interview process, > just like all our wonderful tax preparation software... I think MMD's weakenss in this respect is that for it to be intuitively useful, it needs just the right amount of complexity. You don't want to think about numerical ranking, or placement in a tree of loaded modules which you need to read 10 files to find out (or maybe that you can't find out at all (perhaps a parrot disassembler helps in some cases)), and you don't want to think about rules of a complicated system either. you'd like, ideally, for 95% of the cases to be intuitive as far as writing goes (writing either being taking care of functionality or using it). When writing you usually know what values you're dealing with (or at least you're resolving to know later). In that case, if you can make simple rules with some perl that you know, and they are intuitively ranging from specific to generic in their constraint, you should be happy. For when you're confused or forgetful and the system isn't DWIM enough, i guess %4.5 can be dealt with using errors. I don't know of a method to take care of %0.5 elegantly, but I think that encouraging MMD to not be used in order to lower the actual number that %0.5 is is a bigger mistake. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM: neeyah!
pgpJPtw4t52Mb.pgp
Description: PGP signature
