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

Re: MMD as an object.

Thread Previous | Thread Next
From:
Larry Wall
Date:
March 9, 2005 11:08
Subject:
Re: MMD as an object.
Message ID:
20050309190722.GB25992@wall.org
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.

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.

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.

Larry

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About