On Wed, Jul 13, 2005 at 06:07:55PM +1000, Damian Conway wrote:
> The use of summed lineal distance (L[1]) rather than RMS distance (L[2])
> probably *isn't* superior as a closeness measure. But it's computationally
> much simpler (and hence likely to be more efficient), it doesn't suffer
> from
chromatic wrote:
Why would a class not also define a type?
It does. A class is an instance generator. So all instances
share the same property of 'beeing instanciated from SomeClass'.
This can be used to type them. Question is where this type is
placed in the type lattice and how it compares to
On Tue, 2005-07-19 at 12:37 +0200, "TSa (Thomas Sandlaß)" wrote:
> I would think that the programmer specifies what type a class
> implements by letting it do a set of roles. This implies that
> by default a class does the very unspecific Any.
Why would a class not also define a type?
-- c
HaloO Damian,
you wrote:
No. If the dispatch behaviour changes under a Manhattan metric, then it
only ever changes to a more specific variant.
This statement is contradicting itself. A metric chooses the *closest*
not the most specific target. Take e.g. the three-argument cases
7 == 1+2+4 == 0
HaloO Larry,
you wrote:
Implicit is that role distance is N + the distance to the nearest
class that incorporates that role for small values of N.
If class Dog does role Bark and also does role Wag, then passing a
Dog to
multi (Bark $x)
multi (Wag $x)
should result in ambiguity. The
Luke wrote:
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: "Manhattan distance is
better".
That was never my *argument*, merely my statement-of-position. ;
On Thu, Jul 14, 2005 at 03:27:53PM +1200, Sam Vilain wrote:
: Can I present an alternative way of viewing them, which I don't think
: contradicts with what I've understood of them so far from the
: Apocalypses and Synopses documents.
:
: First a couple of definitions;
:
: A "runtime class" is a
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: "Manhattan distance is
better".
Damian writes:
> Similarly, since the number of potential variants is the Cartes
Larry Wall wrote:
In addition to what chromatic said, I'd like to point out that you've
got the abstraction levels backwards by my lights: these days I
tend to think of the class as a restricted form of role. A class is
restricted to having to provide a working interface to real objects.
Can I
TSa (Thomas Sandlaß) wrote:
I just want to hint the Perl6 community to the fact that there exists
a US patent on geometric MMD:
Well, fortunately it's really just a patent on the specific combination of a
mathematical isomorphism and a well-known geometric algorithm to *optimize*
method disp
(Taking things slightly out of order.)
On Jul 13, 2005, at 7:32 PM, Larry Wall wrote:
A class is
restricted to having to provide a working interface to real objects.
Can't there be pure-abstract, non-instantiable classes? Or are you
still considering those to be interfaces to "real objec
On Wed, Jul 13, 2005 at 05:33:18PM -0400, David Storrs wrote:
: I'd like to have it explained what Roles
: offer that justifies their existence, since they won't be anything
: but a restricted form of a class.
Please check your assumptions.
In addition to what chromatic said, I'd like to poin
On Jul 13, 2005, at 6:16 PM, chromatic wrote:
On Wed, 2005-07-13 at 17:33 -0400, David Storrs wrote:
What is a type besides a named blob of methods
and, possibly, data?
A label that says how the data is stored internally. For example,
compare "Int" and "int". The former is a type and
On Wed, 2005-07-13 at 17:33 -0400, David Storrs wrote:
> > What is a type besides a named blob of methods
> > and, possibly, data?
> A label that says how the data is stored internally. For example,
> compare "Int" and "int". The former is a type and a blob of methods
> and not necessaril
On Jul 13, 2005, at 4:35 PM, chromatic wrote:
On Wed, 2005-07-13 at 16:07 -0400, David Storrs wrote:
My understanding is that a Role is an abstract (i.e. cannot be
instantiated) blob of methods and, possibly, data. The purpose of a
Role is to paste it into a class--in other words, a Role is
On Wed, 2005-07-13 at 16:07 -0400, David Storrs wrote:
> My understanding is that a Role is an abstract (i.e. cannot be
> instantiated) blob of methods and, possibly, data. The purpose of a
> Role is to paste it into a class--in other words, a Role is a not a
> type, it is a part of a type.
On Jul 13, 2005, at 1:12 PM, Larry Wall wrote:
If class Dog does role Bark and also does role Wag, then passing a
Dog to
multi (Bark $x)
multi (Wag $x)
should result in ambiguity.
My understanding is that a Role is an abstract (i.e. cannot be
instantiated) blob of methods and, pos
On Wed, Jul 13, 2005 at 06:11:32PM +1000, Damian Conway wrote:
: TSa (Thomas Sandlaß) wrote:
:
: >>Unique least-inherited most-specialized match, or default
: >
: >
: >Do I read this correctly as dispatching partly in the class hierarchy
: >and partly in the type hierarchy?
:
: Err. The class
HaloO Damian,
thank you very much for your explaination. I just want to hint the
Perl6 community to the fact that there exists a US patent on geometric
MMD:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=ferragina
TSa (Thomas Sandlaß) wrote:
Is there also an answer to the odering versus metric question?
Why was the former rejected and the latter choosen?
MMD is really just a partitioning of the discrete N-dimensional search space
formed by the class hierarchies of the N parameters of a multimethod/mult
TSa (Thomas Sandlaß) wrote:
Unique least-inherited most-specialized match, or default
Do I read this correctly as dispatching partly in the class hierarchy
and partly in the type hierarchy?
Err. The class hierarchy *is* the type hierarchy in Perl 6.
Or do you mean with 'least-inherit
Mark Reed asked:
OK, sorry if I missed this in an earlier discussion. For purposes of
calculating this Manhattan distance, I gather that we're treating lists of N
arguments/parameters as points in N-space. I further assume that the
monoaxial distance between a parameter coördinate and the corr
HaloO Larry,
you wrote:
On Tue, Jul 12, 2005 at 08:13:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Actually it's a pitty, that the multi method call syntax isn't as
: rich as the single method call syntax where we have .?method, .+method
: and .*method. Something like (Snoopy, Mr_PotatoHead, Hope
On Tue, Jul 12, 2005 at 08:13:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Actually it's a pitty, that the multi method call syntax isn't as
: rich as the single method call syntax where we have .?method, .+method
: and .*method. Something like (Snoopy, Mr_PotatoHead, HopeDiamond).*foo
: doesn't exi
Mark Reed wrote:
On 2005-07-12 12:22, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]>
wrote:
I am also interested in the rationale behind the approach to manage MMD
my means of a metric instead of a partial order on the types.
Metric is a geometric concept which in my eyes doesn't fit type
theory.
On 2005-07-12 12:22, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]>
wrote:
> I am also interested in the rationale behind the approach to manage MMD
> my means of a metric instead of a partial order on the types.
> Metric is a geometric concept which in my eyes doesn't fit type
> theory.
The geometri
Damian Conway wrote:
This is a much less dwimmy solution than Yuval's or Luke's, but it has the
advantage that those eight steps reduce to eight words:
Unique least-inherited most-specialized match, or default
Do I read this correctly as dispatching partly in the class hierarchy
and partly
Mark Reed wrote:
And one more dumb question: why is it that the L[1] metric is superior to
the L[2] metric for this purpose?
I am also interested in the rational behind the approach to manage MMD
my means of a metric instead of a partial order on the types.
Metric is a geometric concept which i
On 2005-07-11 23:46, "Damian Conway" <[EMAIL PROTECTED]> wrote:
> 3. Work out the Manhattan distance from the argument list to each
>variant's parameter list.
OK, sorry if I missed this in an earlier discussion. For purposes of
calculating this Manhattan distance, I gather that we're
Yuval asked me off-list if I would comment on the various dispatch algorithms
that have been proposed.
I guess I have used MMD more than most people in this discussion. Indeed,
having both written Class::Multimethods and supervised a PhD that involved
adding MMD to C++, one might have assumed that
Larry wrote:
> I would like to point out that for mere mortals, *any* MMD is already too
> complex to be predictable.
This is the relevant observation here.
This particular mortal's experience is that more than four variants, involving
parameters from more than two hierarchies makes it nearly
31 matches
Mail list logo
