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 a type for multisub dispatch
because they don't have a name to dispatch on.
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.
A case could be made for anonymous multimethod dispatch, since the
list of multi candidates is stored in the class of the first
invocant.
What is the difference between "multimethod dispatch" and "multisub
dispatch"? AFAICS, the term "multimethod" does not appear anywhere in
docs/pdds/.
> (The PDD does mention C<push_pmc> as the PIR API for adding methods to
> multisubs, but such a sub must have already been declared :multi, with
> named classes, so the C<push_pmc> will have been done automatically
> anyway by the loader.) To define a methods that dispatch on anonymous
> classes, one would need to be able to pass an ordinary (non-:multi) sub
> and an array of class objects to the method-adding method. Since it is
> syntactically illegal to put ":invocant" on non-multi subs, either this
> restriction would have to be lifted, or some other means of declaring
> invocant args would be needed, perhaps using a distinguished non-class
> value in the class list.
A .sub has to be declared :multi to be used as a multi sub, even if
stored as a method.
Isn't that currently true only because the type specialization info must
be stored on the Sub before it is added to the MultiSub? If there were
a PIR API to do this, either during the process of adding to a MultiSub
or beforehand, wouldn't that eliminate this restriction?
We could provide a dummy type "SELF" that narrowly
restricts the type match to the class of the first invocant, but it's
only meaningful when :method and :multi are combined.
IIUC, I don't think that would help in my case; CL methods are always
multimethods.
. . .
> As Klaas-Jan pointed out, the magical "_" is not documented. But I
> think we need a better way to specify "any type". First of all, there
> is no way to say "any PMC type" as distinguished from "any register
> type" and "any type at all" (I think "_" means the last alternative,
> true?). Secondly, these types need explicit class names that point to
> explicit class objects, at which point special-casing for "_" (among
> other things) becomes unnecessary.
It's possible to create a variety of pseudo-classes for groupings that
aren't strictly relations of inheritance or composition. But, better to
wait for a specific practical use and implement it when needed.
For the most part, multiple dispatch at least needs to verify some
minimal interface in its invocants, even if that requirement is as
simple as "can act like a number", so differentiating on register type
may not be very useful. Roles are likely to play a strong part.
While I admit I that can't think of a use case for "any register" (I
mentioned that mostly for completeness), I do think that an explicit
"any PMC" class that served as the root of the type hierarchy would
allow us to remove some special cases, starting with the "_" naming hack
Klaas-Jan mentioned. FWIW, Common Lisp uses "T" as the name of the
universal type; everything in a Lisp program isa T. The class object
for T appears in the MRO of other classes and the specializer list of
methods that would use "_" in Parrot -- and I suspect the CL method
dispatch code would be messier without it.
> And somewhere, maybe not here, the type network of all Parrot
> built-ins needs to be specified. This amounts to casting it in stone,
> but if we don't do it explicitly, it will be effectively cast in stone
> by virtue of all the code that will break if we try to change it.
Builtin operations or builtin types?
Built-in types.
For the types, see PDD 17. We won't cast anything in stone, but a
change to the type hierarchy would have a longer deprecation cycle
than more trivial changes.
I was looking for the type network, but I don't see any specification of
PMC inheritance, even in PDD 17. For example, MultiSub is documented in
the "Subroutine types" section, but nowhere does it say that MultiSub is
built on ResizablePMCArray and not on Sub.
As an implementor, I need to know such things. In fact, this very
aspect of MultiSub inheritance tripped me up once; I didn't realize that
FUNCTIONP must test for both classes, since a MultiSub is not a Sub.
And, come to think of it, ARRAYP must also test that its argument is
*not* a MultiSub, so I still have another bug . . .
And the type network needs to be stable, so a long deprecation cycle
is a good thing. I don't really expect casting in stone; firm clay
would be good, that hardens toward the 1.0 release . . . ;-}
> Finally, a question: What is the difference between an :invocant
> parameter that isn't specialized (i.e. specifies "_" as the :multi
> dispatch class), and leaving that parameter out of the :multi list
> altogether? . . .
The latter example, with a non-invocant separating two invocants, isn't
allowed.
Allison
In that case, I don't understand the purpose of flagging invocants at
all. If invocants must be positional and required, must come before all
non-invocant args, and must be the same in number as the :multi classes,
then surely their identities can be inferred?
TIA,
-- Bob
