On Tue, Jul 16, 2002 at 03:35:30PM -0500, David M. Lloyd wrote:
On Mon, 15 Jul 2002, John Porter wrote:
There is really no inheritance of any kind going on,
it just sticks pointers to the default functions into the vtable
structure method entries for undefined methods.
But that's
On Mon, 15 Jul 2002, John Porter wrote:
David M. Lloyd wrote:
Do we really want *two* inheritance trees per object
in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
Ugh.
The MM dispatch problem is pretty much solidly in
the realm of pmc
David M. Lloyd wrote:
John Porter wrote:
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance,
There _is_ no pmc inheritance right now.
There's just a set of default functions.
Call it what you want.
The point is that this type schema is at the parrot level,
John Porter wrote:
The point is that this type schema is at the parrot level,
and is not the concern of a user-level language like perl
Of course this is not really true; perl scalars, arrays, and
hashes (etc.?) are implemented as PMCs under the hood, so
in that sense they are related by
On Tue, 16 Jul 2002, John Porter wrote:
David M. Lloyd wrote:
John Porter wrote:
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance,
There _is_ no pmc inheritance right now.
There's just a set of default functions.
Call it what you want. The point is
David M. Lloyd wrote:
No, the point is that all this talk about type-space mm dispatch
depends on there *being* type space. Since there is currently
no inheritance to speak of then there really is no typespace so
all of this talk is moot,
I agree; but you did express a concern earlier that
On Wed, 10 Jul 2002, Dan Sugalski wrote:
What bothers me is this: the programmer needs to be able to predict
what the machine is going to do with the code she gives it.
And predicting how the machine is going to resolve the multimethod
call could be, in any but trivial cases, far too
David M. Lloyd wrote:
Do we really want *two* inheritance trees per object
in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance, and that's something
we have control
--- Dave Mitchell [EMAIL PROTECTED] wrote:
On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
Nicholas Clark wrote:
I was thinking that the metric (x*x + y*y) would be fast to
calculate, as that's all we need for ordering.
Point is, it's rather *more* than we need for
On Thu, Jul 11, 2002 at 08:20:21PM -0700, John Porter wrote:
Dave Mitchell wrote:
IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
are strongly equivalent, ie they give rise to the *same* ordering.
(In the limit as n - Inf, the metric is max(x,y).)
I'm sorry, YDNRC.
Brent Dax wrote:
Nicholas Clark wrote:
Unless I'm being thick, x² y² whenever x y for positive x
and y (ie you don't need to take the square root of the
hypotenuse to work out which hypotenuse is shorter. And all
we're actually interested in which one is shorter, aren't we?)
Dan Sugalski wrote:
lookup is O(n) since we precompute the dispatch table.
Oh. So the cost of computing the table is amortized over all the
mm calls that go to the table for resolution. Could be Bad,
for the typical small Perl program.
Then there's the issue of the size of the table.
At 6:15 PM -0700 7/10/02, Brent Dax wrote:
Nicholas Clark:
# On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
#
# Dan Sugalski wrote:
#
# Heh. I never expected to have to dust off my trig skills when I
# started this. If I need to dig out the calculus books, I
# think I'll
#
Dan Sugalski wrote:
Nicholas Clark:
Unless I'm being thick, x y whenever x y for positive x
and y (ie you don't need to take the square root of the
hypotenuse to work out which hypotenuse is shorter. And all
we're actually interested in which one is shorter, aren't we?)
We can also
Dan Sugalski wrote:
That trades space for speed,
Ain't it always the way. ! :-)
In general that's potentially unbounded, but for the specific
case of PMC vtable methods it's a fixed number.
It gets more interesting for general methods and subs,
but we can deal with that a bit later.
On Wed, 10 Jul 2002, Nicholas Clark wrote:
Dan Sugalski wrote:
Heh. I never expected to have to dust off my trig skills when I
started this. If I need to dig out the calculus books, I think I'll
just go run screaming...
Unless I'm being thick, x² y² whenever x y for positive
Andy Dougherty wrote:
Assuming x and y are coordinates in a 2-d space, and that both are
integers = 0, why not just use what is affectionately called the
taxicab metric: x+y? It is just as valid and even quicker to
compute than the Euclidean metric sqrt(x^2 + y^2).
Yes! Very incisive
On Thu, Jul 11, 2002 at 10:52:31AM -0700, John Porter wrote:
Dan Sugalski wrote:
Nicholas Clark:
Unless I'm being thick, x y whenever x y for positive x
and y (ie you don't need to take the square root of the
hypotenuse to work out which hypotenuse is shorter. And all
we're
Nicholas Clark wrote:
I was thinking that the metric (x*x + y*y) would be fast to
calculate, as that's all we need for ordering.
Point is, it's rather *more* than we need for ordering.
x + y will suffice.
And I live in London, where we don't have a regular grid of
streets, so our taxis
At 8:58 PM +0100 7/11/02, Nicholas Clark wrote:
On Thu, Jul 11, 2002 at 10:52:31AM -0700, John Porter wrote:
Dan Sugalski wrote:
Nicholas Clark:
Unless I'm being thick, x y whenever x y for positive x
and y (ie you don't need to take the square root of the
hypotenuse to work
On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
Nicholas Clark wrote:
I was thinking that the metric (x*x + y*y) would be fast to
calculate, as that's all we need for ordering.
Point is, it's rather *more* than we need for ordering.
x + y will suffice.
IIRC, all metrics of
Dave Mitchell wrote:
IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
are strongly equivalent, ie they give rise to the *same* ordering.
(In the limit as n - Inf, the metric is max(x,y).)
I'm sorry, YDNRC.
Consider the distance from the origin to the points (0,6) and (3,4).
At 8:35 PM -0700 7/9/02, John Porter wrote:
Dan Sugalski wrote:
John Porter wrote:
Why is left side wins insufficient?
Well, perl 5 is apparently not left side wins for overloading, which
is enough.
Mmmm. Have a good example handy?
I'll have to go dig one up. Damian hit me with the
Dan Sugalski wrote:
What we're
doing is assuming we don't know and letting the variables decide
whether they'll care. Perl's will, though other languages can decide
differently.
Letting the variables decide?
So, we take a poll of all the arguments, and ask each one
which they think ought
On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
Dan Sugalski wrote:
Heh. I never expected to have to dust off my trig skills when I
started this. If I need to dig out the calculus books, I think I'll
just go run screaming...
Not to worry. There's no trig involved.
At 10:17 AM -0700 7/10/02, John Porter wrote:
Dan Sugalski wrote:
What we're
doing is assuming we don't know and letting the variables decide
whether they'll care. Perl's will, though other languages can decide
differently.
Letting the variables decide?
So, we take a poll of all the
Nicholas Clark:
# On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
#
# Dan Sugalski wrote:
#
# Heh. I never expected to have to dust off my trig skills when I
# started this. If I need to dig out the calculus books, I
# think I'll
# just go run screaming...
#
# Not to
On Sun, 7 Jul 2002, Dan Sugalski wrote:
Basically what we need is a lookup matrix for each vtable method
(add, subtract, multiply, whatever) that we can index by left and
right types to get the actual method to call.
I suppose resolution based on distance in number-of-args dimensional type
At 2:08 PM -0700 7/7/02, Sean O'Rourke wrote:
On Sun, 7 Jul 2002, Dan Sugalski wrote:
Basically what we need is a lookup matrix for each vtable method
(add, subtract, multiply, whatever) that we can index by left and
right types to get the actual method to call.
I suppose resolution based
At 2:08 PM -0700 7/7/02, Sean O'Rourke wrote:
On Sun, 7 Jul 2002, Dan Sugalski wrote:
Basically what we need is a lookup matrix for each vtable method
(add, subtract, multiply, whatever) that we can index by left and
right types to get the actual method to call.
I suppose resolution based
We need a multimethod dispatch for vtable calls. Right now we're
working on a left side wins scheme and, while we're going to keep
that (sort of) we really need a way to choose the method to call
based on the types on both sides of binary operators. (Unary
operators, luckily, are easier)
31 matches
Mail list logo
