This is a draft of nothingmuch's proposition.

Current defined semantics are: matches are tried in order of definition.

That sucks because you can't append more specific versions of a method to the
definition, thus making the handling of a special case simpler.

So much for post-modern programming.


MMD order of particularity:

	1. values and value junctions (4|5 will match 4)
		- specifity is judged by comparing trees
			- each OR is a branch to the side
			- each AND is another level of depth
			- the tree is 'drawn' with right angles
			- the ratio between the height and width of the area needed to draw
			  the tree is the score of the junction
			- ratios which are too close to each other in a single definition
			  are a compile time error
		- simple values are the median case (between ANDIshness and ORishness)
		- overloaded equality operations are really more like where clauses
	2. value ranges (1 .. 10 will match 5) (possibly junctive, see 1.)
	3. type matching (possibly junctive, see 1.):
		3.1 Exact class of value
		3.2 Superclasses sorted on single vector
			- Any multiply inheriting invocant with more than one matching
			  superclass type in differring multis is a dispatch error (try
			  compile time error at def time, if there is a known class for the
			  possible instance?)
		3.3 Specific role composite
			- specifity: role x does role y. class c does role x, so it also
			  does role y. In this case role 'x' will win role 'y' in a
			  signature
			- tie: However, class 'd' does role 'm' and role 'n'. The two are
			  tied. This is fatal, just like MI ties (even though MI could in
			  theory have a "better" match, IMHO it should be avoided.)
			- paramaterized roles are equal to an anonymous role, consuming
			  it's generic for the purpose of dispatching
	4. the any type


Merging the Junction/Value step:

An idea for particularity ordering - junctions that are ANDish are more
particular than simple values.

A simple value is just the median weight junction.

I think this can be both good and bad for simplicity.


Back to the dispatch logic...  When a list of possible matches is defined, the
where clauses are tried in order, from best to worst match

the first one whose where clause passes will win.

Where clauses are short circuiting in the sense that a where clause will not be
executed if one before it in the same signature failed

Where clauses will not be executed until the whole signature is known to check
out in terms of equality and other constraints. Hence the seperation into two
steps.



Paramater coercion:

If no sub matches, all MMD candidates are retried, with the following algorithm:

	skip unless parameter list matches (without any type/value constraints)

	do an MMD lookup for the short name 'coerce' with every parameter such that

		sub coerce($concrete_value_we_are_trying_to_bind)
			returns $parameter_we_are_trying_to_bind_value_into;

	(this is MMD on the return type of the function)

	When all parameter candidates have been satisfied, execute the 'where'
	clauses of the 'coerce' matches. Skip unless all match.

	When all coerce routines are known to be working, apply them one by one.
	Any fails or errors mean the next MMD candidate will be tried instead.

Coercion of an 'is rw' field must be done manually outside MMD. Good style is
creating a &original.wrap with an MMD signature of the type we're coercing from
that takes care of the bidirectional conversion.

On ties and ambiguity:

Ties are a fatal error, preferably at compile time.

If there are two MMD signatures that have a competing signature, then they cannot coexist.

The only exception to this rule is that given a conflict, a special error
handler could be used by the consuming code to redefine some of the MMD - take
preference, redefine a signature, and so forth.

Runtime errors can be avoided by using a lexical pragma at the caller level.
This is off by default. If that is the case, tye breaking semantics are as such:

	In a given file the method occurring BEFORE another is the default

	In the whole program the method occurring in a LATER file is the default

When this is forced, a warning is emitted unless in addition to the 'use
mmd::insanity' pragma the user has 'no warnings mmd::insanity'.

Both pragmas are lexical to the code making the call.

~~~~~~~~~~~~~~~~~

Here is a different proposal (Luke's) for MMD matching which involves solving
the Halting problem because of subtypes.  He hopes to create a sane compromise
between the above proposal and this one.

Multimethods have a partial ordering.  If more than one multimethod is
applicable to a given call, then if there is one multimethod that is "less
than" all the others, it gets called, otherwise it is ambiguous.

In the following description, a type is taken to mean the set of objects that
it represents.

Given two multimethods A and B, A < B iff
    * Every invocant parameter in a has a corresponding parameter in B such that
        A's parameter's type is a subset of B's parameter's type.
    * At least one of these subsets is a proper subset.

It is easy to show that this relation is transitive.  I argue that these are
very logical semantics, and would work perfectly if we could determine all
subset relationships between all involved types.  Alas, that's equivalent to
the Halting problem.

Here are the assumptions that avert the Halting problem and merge the above
proposal with this one:

    1) All relationships are assumed to be predeclared. 
    2) There are no null levels of composition or inheritance.
    3) All direct subtypes of a given (particular) type are assumed to be disjoint.
    4) Exact values and ranges are more specific than any other declared subtype (and
        the subset relationships between those can be determined statically).

Concequences of (1):

    * Both A and B are proper subsets of A|B (unless A and B are related, in which case
        the junction is equivalent to the more general one).
    * A&B is a proper subset of both A and B (unless A and B are related, in which case
        the junction is equivalent to the more specific one).

Concequences of (2):

    * All inheritance relationships and role compositions create proper subsets.