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 a
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
pa
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 e
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 :mult
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 t
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 mul
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 sh
--
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 n
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 :mult
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 regis
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
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
pd
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 allo
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 s
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 :mult
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),
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 groupi
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 classes?
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 :mult
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
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 ma
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
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
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 h
Klaas-Jan Stol wrote:
looks good as far as I can tell. W.r.t. the selection part, the "don't care" type is
missing, which is "_" IIRC.
My guess is that if you can specify which parameters are invocants, with
:invocant, then the need for an "any" type goes away, since you just
don't mark the
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,
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
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
===
28 matches
Mail list logo
