David Storrs wrote:

On Jul 8, 2005, at 4:25 PM, Dave Whipp wrote:

Rod Adams wrote:

   multi method foo#bar (Num x) {...}
   multi method foo#fiz (String x) {...}
   $y = 42;
   $obj.foo#fiz($y); # even though $y looks like a Num
   $obj.foo($z);     # let MMD sort it out.

Instead of changing the parse rules for #, why not just use a trait?

    multi method foo is short_name('bar') {...}

I thought about that, but then thought that to become commonplace it was a bit much to type. I also couldn't come up with a way to call a given multi that matches on a given attribute, without adding even more complexity to MMD.

Having additional tags might also give us something to hang priority traits off: "foo#bar is more_specific_than(foo#baz);" might influence the order of clauses in the implicit given/when block. It feels like there should be a generalization of operator precidence here (even thought he two are superficially dis-similar, the looser/tighter concept appears valid).

Although I like the idea of reusing this concept, I'm not sure that it really solves the problem. Fundamentally, we're trying to make MMD behave intuitively with no programmer effort.

Well, if one views MMD as "a list of methods to try, each with it's own requirements on it's arguments", then it can completely solve the problem, along with a method sort function.

1) take all methods the user specified "higher than/lower than/equal to" out of the mix.
2) sort remaining methods via a standardized function.
3) put all the ones taken out in step 1 back in, where they are requested.
4) scan the methods, in order, for the first that accepts the given arguments.
5) dispatch to the chosen one in #4
6) begin AUTOMETHing, etc.

Then all we need is a DWIMish sort function.

Some ideas:
-- longer parameter lists go before shorter ones.
-- if param(n) of one ISA param(n) of another, it goes first.
-- slurpies after non-slurpies
-- a hashkey of the parameter types (for deterministic coin flips)

I'm not committed to what goes into the method sort function, or in what order, just the concept of it. To me it seems easier to visualize than distances, etc. If nothing else, it should be easy to explain to users and programmers.

With the name tagging idea from before, one could then say things like:

   multi sub foo#lastresort ([EMAIL PROTECTED]) is after(foo#default) {...}

for when the default sort does things incorrectly.

A reasonable extensions of this would be to have a coderef attribute that determines if a supplied set of arguments is acceptable, rather than the default check. This is a possible MTOWTDI for the 'where' clauses.

Then again, there are likely several glaring problems with this idea that I'm just not seeing at the moment.

-- Rod Adams

Reply via email to