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.
> >
>
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 t
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 w
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 wha
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
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 re
"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
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
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, YD
--- 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 w
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).
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 metr
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
>> >
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
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
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 inci
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 <
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.
At 9:50 AM -0700 7/11/02, John Porter wrote:
>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.
More
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?)
>
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
># thi
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.
Consid
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 w
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...
# >
# >
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 a
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 invo
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 ou
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 hi
> 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 easie
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 resolutio
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 resolutio
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
32 matches
Mail list logo
