Larry Wall wrote:
On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote:Well, my intent was that one should be assigning the policy to a given multi, not a given scope. If people wish to change the default policy for multis defined in a given scope, I have no problems with that.
: I was thinking more along the lines of :
: : use MMD::Pattern;
: : our &func is MMD::Pattern;
: : multi func (...) {...}
: multi func (... ...) {...}
: multi func (... ... ...) {...}
: : multi func2 (...) {...}
: multi func2 (... ...) {...}
: multi func2 (... ... ...) {...}
: : Where &func would get Pattern MMD, and func2 would get Manhattan MMD.
Might be better to define some modifiers other than "multi" just for the
documentation value, if you're going to have different policies in the
same file like that. I expect that's a rarity, though. Most files
would have a single MMD policy.
The reason for binding the policy to a given multi was so people could write a package Foo with a pack of multi sub bar's, using policy MMD::Random, and export into a different scope, but still have the caller use the Random policy when calling bar.
I'm going to interpret this as "This is a solvable problem that just needs a little optimization in the compiler."But the main problem I see with all this is that MMD is supposedly combining short names from potentially many different scopes across *multiple* files, and what do you do if those have different policies? Plus the OP assumed that all instances of a particular short name are represented by a single object, which is not necessarily the case, since different lexical scopes can see different (and potentially overlapping) sets of multis with the same short name. I suppose one could get around that by placing an implicit constraint on multis you're not supposed to be able to see, though. Except that you really need unique long names as well within one of these objects, and two completely distinct lexical scopes could have long names that would be confused with each other. Oh wait, the lexical scope constraint would be part of the long name, just like any other constraint. Nevermind. Though maybe you still want to have separate objects since it's a performance hit to actually evaluate constraints at run time.
Please correct me if this a poor interpretation.
But we still have the problem of conflicting policies in differentThe problem with this is that it requires people to be very cooperative with how they assign their scalar values. And that feels like asking for trouble.
scopes. Maybe it's not a problem if we view different policies as just
different ways of marking autogenerated signatures with distance, if
we can come up with a single underlying *scalar* distance measure that
different policies can map multidimensional distances to differently.
Some policies might only choose between 0 and Inf for the scalar
distance, for instance, while others might try to finesse additional
distance values. It seems to me that both the manhattan scheme and
the pure scheme can be subsumed under that, but I could be wrong.
I think a better solution is to make it where a given short name can only have one policy. Trying to assign two policies to the same multi would be a warning at least, and preferably an error.
There lingers the case of:
use Foo; # from above, exports &bar is MMD::Random
multi sub bar {...}Does this generate an error, since one could expect this particular &bar to be Manhattan? Or does it assume Random, since there's already a &bar in existence? In my head, it currently makes sense to say that the new &bar inherits the Random policy. Only something like:
use Foo; our &bar is MMD::Manhattan;
multi sub bar {...}Would trigger an error.
-- Rod Adams
