Okay, here's an issue for everyone. I'm writing the MMD subsystem, at
least the parts needed for operator overloading, and I'm coming across the
need to defer adding functions. For example, the Float class has functions
for the Integer class, and vice versa, and we can't guarantee that both
Dan Sugalski wrote:
Okay, here's an issue for everyone. I'm writing the MMD subsystem, at
least the parts needed for operator overloading, and I'm coming across the
need to defer adding functions. For example, the Float class has functions
for the Integer class, and vice versa, and we can't
On Mon, 29 Sep 2003, Mark A. Biggar wrote:
Dan Sugalski wrote:
Okay, here's an issue for everyone. I'm writing the MMD subsystem, at
least the parts needed for operator overloading, and I'm coming across the
need to defer adding functions. For example, the Float class has functions
for
On Mon, Sep 29, 2003 at 10:28:25AM -0400, Dan Sugalski wrote:
On Mon, 29 Sep 2003, Mark A. Biggar wrote:
Isn't there also the option to force load the missing class(es)
recursively?
We could, but I don't want to do that here. Just because a PMC class
presents functions for other PMC
On Mon, Sep 29, 2003 at 10:00:09AM -0400, Dan Sugalski wrote:
So, I've two options:
1) When one or both of the classes a MMD function is installed for don't
exist, we give them both class numbers (but don't load them) so when the
classes *are* later loaded they already have numbers
2) We
On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
You must not be following Perl 6 closely enough, then. Perl 6 is a
real programming language now, as opposed to a scripting language.
Um, I've followed Perl6 closely enough to know that the distinction
between real langauge and
Adam Turoff writes:
On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
It will still have a lot of power in text processing, and still be a
powerful quicky language, but that's no longer its primary focus --
not to say that highly structured programming is. Some applications
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
What it seems you're wanting is it to be in the core. And I'm saying
that's irrelavent. There are thousands of great ideas out there, and
they can't all fit into Perl's core. That's why there's thousands of
modules on CPAN.
Have
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
And I don't see what's stopping someone from writing Dispatch::Value.
use Dispatch::Value;
sub foo($param is value('param1')) {...}
sub foo($param is value('param2')) {...}
What it seems you're wanting is it to be in
A better fitting solution wouldn't focus on classic
MMD, but simply Dispatch, where type- and value-based
dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls are
[EMAIL PROTECTED] (Luke Palmer) writes:
It will still have a lot of power in text processing, and still be a
powerful quicky language, but that's no longer its primary focus --
not to say that highly structured programming is.
So, uh, what is?
And you can still do it the Perl 5 way in Perl
Apologies if I've missed some earlier discussions on multimethods. The
apocolypses, exegesises and synopses don't seem to say much other than
(a) they will exist and (b) wait for apocolypse 12 for more information.
Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
intent is
Apologies if I've missed some earlier discussions on multimethods. The
apocolypses, exegesises and synopses don't seem to say much other than
(a) they will exist and (b) wait for apocolypse 12 for more information.
Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
At 9:27 PM -0400 9/4/02, Ken Fox wrote:
Dan Sugalski wrote:
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
So, just to clarify, does that mean that multi-dispatch is (by definition)
a run-time thing, and overloading is (by def) a compile time thing?
No. They can be both compile time things or
From: Ken Fox [EMAIL PROTECTED]
Over loading is what C++ has. It is not the same as
multi-dispatch. The trouble with over loading is that the
compiler uses static (compile-time) type information to
select the over loaded method. This can create subtle
bugs when people try to re-use code by
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
From: Ken Fox [EMAIL PROTECTED]
Over loading is what C++ has. It is not the same as
multi-dispatch. The trouble with over loading is that the
compiler uses static (compile-time) type information to
select the over loaded method. This can
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
No. They can be both compile time things or runtime things, depending
on the characteristics of the language.
So if it's compile-time for a given language, how is it different from
the Java concept of overloading?
And will
At 7:31 AM -0700 9/4/02, David Wheeler wrote:
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote:
No. They can be both compile time things or runtime things,
depending on the characteristics of the language.
So if it's compile-time for a given language, how is it different
from
(), but that's the whole
point of overloading and multimethod dispatch, isn't it?
The usual list context / scalar context distinction would of course still be possible.
It's just about _extending_ context sensivity.
[Comments | Suggestions | Criticism] welcome.
of the method). I believe this is what has
been referred to as multimethod dispatch on this thread.
An overridden method is two methods with the same name AND type
signature in two different classes, where one class is a subclass
of the other. The child class's method is said to override
Dan Sugalski wrote:
Dan, can you explain what multimethod dispatch is?
Damian can explain it better than I can,
I thought you did a great job!
However, anyone who wants to know more about multiple dispatch
might also like to read:
http://www.samag.com/documents/s=1274/sam05010010
Dan Sugalski wrote:
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote:
So, just to clarify, does that mean that multi-dispatch is (by
definition)
a run-time thing, and overloading is (by def) a compile time thing?
No. They can be both compile time things or runtime things, depending on
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?)
; the int isn't promoted to a float.
Ah. In that case it's really a subset of multimethod dispatch,
a subset of?
It *is* multimethod dispatch, but for just a pre-defined
subset of cases. Is that what you mean?
If we can't find a match, or ... no clear winner,
we throw an exception
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).
a possibility,
so we have to address it. As in the case of int-vs-float, maybe a
kind of paper-scissors-rock rulebase that orders types.
(What C/C++ hard-codes as type promotion.)
Type promotion makes me more nervous than multimethod dispatch. I
think I'd rather not do that unless we really have
more nervous than multimethod dispatch.
I think I'd rather not do that unless we really have to.
But I'm not talking about actually doing type promotion; it's
just a scheme to decide who gets to decide.
In the example of int-vs-float, the rulebase (it's really just
a DAG) decides that float wins
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.
the arguments, and ask each one
which they think ought to be the receiver?
That would be O(n^2) in the number of args.
Sort of. That's what the multimethod dispatch table does, though
lookup is O(n) since we precompute the dispatch table. We look for
the entry in the table based on the type of the left
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
Okay, now that the dust from YAPC has settled and the holidays and
such are done, it's time to get to some of the outstanding bits of
Parrot. I'm going to get the extension mechanism designed over the
next few days, but until then...
We need a multimethod dispatch for vtable calls. Right now
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
of macros for changing
C strings, to Perl strings, to Unicode strings, and so on. This
multimethod dispatch would make that work at the Parrot level, and just
further the goal of inter-dynamic-language co-operation.
In my opinion, this would provide
several benefits over the current system. While (IMHO
corwin.dreamcafe.com
*/
- Original Message -
From: Michel J Lambert [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 07, 2002 4:46 PM
Subject: Re: Multimethod dispatch for parrot?
Yes. We will, for actual method and sub dispatch. Not for the other
vtable methods, though.
I guess my
On Thu, Mar 07, 2002 at 09:50:01PM +, Tim Bunce wrote:
On Thu, Mar 07, 2002 at 01:48:49PM -0500, Dan Sugalski wrote:
Someone said:
First, there are basic native types such
as num, int, and string, which I'm perfectly fine with. But what bothers
me is the fact that bigint's and
Heya,
I was curious if anyone has ever considered implementing multimethod
dispatch (MMD) directly into parrot. In my opinion, this would provide
several benefits over the current system. While (IMHO) MMD provides many
benefits over the current system in terms of extensibility and ease
Michel J Lambert:
# I was curious if anyone has ever considered implementing multimethod
# dispatch (MMD) directly into parrot. In my opinion, this would provide
# several benefits over the current system. While (IMHO) MMD
# provides many
# benefits over the current system in terms
On Thu, Mar 07, 2002 at 01:48:49PM -0500, Dan Sugalski wrote:
First, there are basic native types such
as num, int, and string, which I'm perfectly fine with. But what bothers
me is the fact that bigint's and bignum's are being given a special place
in the vtable.
Why? They're base
With the possibility of making this thread off-topic: isn't multi-method a
function that propogates according to the values of more than one
argument? Like:
sub myfunc
{
my ($a, $b) = @_;
if ($a-isa('Vector3') $b-isa('Vector3'))
{
return
61 matches
Mail list logo
