Some further thoughts:
Essentially, this could be done as an extension of the versioning
system. The difference between "possrep" versioning and normal
versioning would lie in the means by which the possrep dimension would
be resolved if not specified. Namely, the compiler would make the
decision based on the natures of the various classes and the
preferences of the various function calls. To illustrate, let's say
that we have two implementations for Complex: one that's optimized for
rectilinear coordinates, and another that's optimized for polar
coordinates.
class Complex:opt<rect> { ... }
class Complex:opt<polar> { ... }
...where "opt" is short for "optimized implementation". Both
implementations of Complex would be able to use rectilinear and polar
accessors; indeed, the assumption is that both are capable of handling
the exact same interfaces, differing only in terms of how well they
handle various aspects thereof.
A routine's signature could then include a request for one or the
other - say, something like:
sub foo(Complex:opt<polar>) { ... }
This would not _require_ that a Complex:opt<polar> be provided; only
that a Complex be provided. But if I were to say "my Complex $x;",
followed by a large number of "foo $x" calls, the compiler might
choose to implement $x as a Complex:opt<polar>.
More radically, the sig might be able to provide a priority number as
well as an "option name": e.g., 0 for "this is just a suggestion"; 1
for "it's strongly recommended that you supply this implementation";
and 2 for "do whatever it takes to supply this implementation". So:
sub foo(Complex:opt<rect 1>) { ... }
sub bar(Complex:opt<rect 0>) { ... }
...Would mean that if you try to hand foo a Complex:opt<polar>, foo
will coerce it into a Complex:opt<rect> before using it; whereas bar
would accept it as is. But if the compiler sees that a lot of bar $x
calls are coming up, and $x is currently a Complex:opt<polar> (or it's
at the declarator and no implementation preference has been given), it
might convert $x to a Complex:opt<rect> before it gets to the first of
them, just to smooth the way.
--
Jonathan "Dataweaver" Lang
