develooper Front page | perl.perl6.language | Postings from March 2005

Re: MMD as an object.

Thread Previous | Thread Next
Rod Adams
March 9, 2005 13:43
Re: MMD as an object.
Message ID:
Larry Wall wrote:

>On Wed, Mar 09, 2005 at 06:19:25AM -0600, Rod Adams wrote:
>: 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.
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.

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.

>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.
I'm going to interpret this as "This is a solvable problem that just 
needs a little optimization in the compiler."
Please correct me if this a poor interpretation.

>But we still have the problem of conflicting policies in different
>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.
The 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 

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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About