From: Allison Randal [EMAIL PROTECTED]
Date: Thu, 27 Dec 2007 19:15:40 +0200
Bob Rogers wrote:
Thought so. I ask because Common Lisp has provision for anonymous
classes, and I was wondering how I might support that some day. But my
interest is just academic curiosity at
Will Coleda wrote:
Yes, it would be specified as Int/Str/Num in the signature. But
then invoking the multi with an I register or integer constant
should recognize 'Int' as being a match, and not just 'Integer'.
My concern here is HLL interop. I think it would be cleaner to specify
the base
Klaas-Jan Stol wrote:
Earlier I read over this, thinking: there's probably a good reason for that
(the need for being contiguous), but I haven't figured it out yet.
For sake of documentation, could you please explain why this is so?
so, why would it not be possible to write this:
sub foo
On Dec 29, 2007 11:34 AM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
Earlier I read over this, thinking: there's probably a good reason for
that
(the need for being contiguous), but I haven't figured it out yet.
For sake of documentation, could you please explain why
Klaas-Jan Stol wrote:
In order to solve that, adding a :invocant('any') (* a special marker would
be more convenient, maybe someone would like to define a class 'any' (you
never know :-) but that's beside the pointnow *)
By adding these markers, what effectively happens is that all :invocant
--
Will Coke Coleda
On Dec 27, 2007, at 1:09 PM, Patrick R. Michaud [EMAIL PROTECTED]
wrote:
On Thu, Dec 27, 2007 at 07:56:35PM +0200, Allison Randal wrote:
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
With autoboxing/unboxing, there's not
On Friday 28 December 2007 04:15:03 Will Coleda wrote:
My concern here is HLL interop. I think it would be cleaner to specify
the base types ( or perhaps a does ) to be generic enough to let
another language invoke your multis.
With regard to autoboxing situations, you think the compiler
On Fri, Dec 28, 2007 at 12:37:56PM -0800, chromatic wrote:
On Friday 28 December 2007 04:15:03 Will Coleda wrote:
My concern here is HLL interop. I think it would be cleaner to specify
the base types ( or perhaps a does ) to be generic enough to let
another language invoke your multis.
Klaas-Jan Stol wrote:
we just removed the .pcc_ prefix... (i know, only from some other
directives...) :-P
anyway, the .invocant, .arg , .result and other directives are grouped
together already by the .begin_call/.end_call directives. IMHO, we don't
need a prefix to indicate such a grouping.
On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
With autoboxing/unboxing, there's not really a need to differentiate
between the PMC Integer/String/Float types and the I/S/N registers.
Coming into this discussion from the middle (and having not read
pdd15 in great detail),
Bob Rogers wrote:
Thought so. I ask because Common Lisp has provision for anonymous
classes, and I was wondering how I might support that some day. But my
interest is just academic curiosity at this point, because I'm (still)
nowhere near implementation.
CLOS dispatches on anonymous
Allison Randal wrote:
.param pmc a :invocant(['Foo'; 'Bar'])
And this has me wondering, for languages that do strict type-checking,
will they want to be able to specify the types of non-invocant
parameters? So, maybe that should be:
.param pmc a :type(['Foo'; 'Bar']) :invocant
To
On Thu, Dec 27, 2007 at 07:26:30PM +0200, Allison Randal wrote:
Agreed. (It's worth noting that the problem existed before :invocant was
added.) Adding :invocant, and giving it a string parameter, means we
could do away with the list of types on the :multi flag (we'd still need
the :multi
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:26:30PM +0200, Allison Randal wrote:
Agreed. (It's worth noting that the problem existed before :invocant was
added.) Adding :invocant, and giving it a string parameter, means we
could do away with the list of types on the :multi flag (we'd
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
With autoboxing/unboxing, there's not really a need to differentiate
between the PMC Integer/String/Float types and the I/S/N registers.
Coming into this discussion from the middle (and having not read
On Thu, Dec 27, 2007 at 07:56:35PM +0200, Allison Randal wrote:
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
With autoboxing/unboxing, there's not really a need to differentiate
between the PMC Integer/String/Float types and the I/S/N registers.
On Thu, Dec 27, 2007 at 07:45:03PM +0200, Allison Randal wrote:
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:26:30PM +0200, Allison Randal wrote:
Agreed. (It's worth noting that the problem existed before :invocant was
added.) Adding :invocant, and giving it a string parameter, means
On Dec 25, 2007 4:37 PM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
I guess you're right :-) I was thinking of ambiguity, like
sub foo :multi(Integer, Integer)
.param pmc i :invocant
.param pmc j
.param pmc k :invocant
end
sub foo :multi (Integer, Integer)
On Dec 25, 2007 4:37 PM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
I guess you're right :-) I was thinking of ambiguity, like
sub foo :multi(Integer, Integer)
.param pmc i :invocant
.param pmc j
.param pmc k :invocant
end
sub foo :multi (Integer, Integer)
Klaas-Jan Stol wrote:
I guess you're right :-) I was thinking of ambiguity, like
sub foo :multi(Integer, Integer)
.param pmc i :invocant
.param pmc j
.param pmc k :invocant
end
sub foo :multi (Integer, Integer)
.param pmc j :invocant
.param pmc k :invocant
end
but I guess parrot will see
Bob Rogers wrote:
I notice that this doesn't allow for anonymous classes, since provision
is made only for named classes. Is anonymous class support in prospect?
You can't use an anonymous class as a type for multisub dispatch because
they don't have a name to dispatch on. A case could be
From: Allison Randal [EMAIL PROTECTED]
Date: Tue, 25 Dec 2007 18:16:48 +0200
Bob Rogers wrote:
I notice that this doesn't allow for anonymous classes, since provision
is made only for named classes. Is anonymous class support in prospect?
You can't use an anonymous class as
From: [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 00:53:12 -0800 (PST)
Author: allison
Date: Thu Dec 20 00:53:11 2007
New Revision: 24108
Added:
trunk/docs/pdds/pdd27_multiple_dispatch.pod
. . .
[pdd] Launch the Multiple Dispatch PDD.
I notice that this doesn't allow
Author: allison
Date: Thu Dec 20 00:53:11 2007
New Revision: 24108
Added:
trunk/docs/pdds/pdd27_multiple_dispatch.pod
Changes in other areas also in this revision:
Modified:
trunk/MANIFEST
Log:
[pdd] Launch the Multiple Dispatch PDD.
Added: trunk/docs/pdds/pdd27_multiple_dispatch.pod
Hi,
Just given this a quick read over; looks pretty good. The only thing I
don't see is a way to get the Sub PMC that is going to be invoked
without actually invoking it. Invoke does the lookup and then the call,
but what if I want to supply the arguments, and then just work out what
will be
hi,
looks good as far as I can tell. W.r.t. the selection part, the don't care
type is missing, which is _ IIRC.
So,
.sub foo :multi(Integer,_,_)
.param pmc i :invocant
.param pmc j
.param pmc k
.end
(must j and k be flagged as :invocant?)
then this foo can be invoked with 2 parameters,
I guess you're right :-) I was thinking of ambiguity, like
.sub foo :multi(Integer, Integer)
.param pmc i :invocant
.param pmc j
.param pmc k :invocant
.end
.sub foo :multi (Integer, Integer)
.param pmc j :invocant
.param pmc k :invocant
.end
but I guess parrot will see that the other foo
27 matches
Mail list logo
