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? What does it dispatch on in the
absence of a name? A class object (or equivalent)?
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/.
It's not discussed as "multimethod dispatch", but a MultiSub can be
stored and invoked as either a sub or a method (search for
"multi-method" in PDD 15). Multimethod dispatch respects the inheritance
rules of the language, so a child class can inherit multimethods from
its parent, and a non-multi method declared in a child class will
override (hide) a multimethod declared in its parent class.
Multisub dispatch is a global lookup across all variants.
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?
No, it's because :multi is what tells the parser to allow multiple
variants. Otherwise, declaring another subroutine with the same name is
ignored.
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.
The combination of :method and :multi is what identifies a multimethod.
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.
With autoboxing/unboxing, there's not really a need to differentiate
between the PMC Integer/String/Float types and the I/S/N registers.
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 . . .
At the moment, the documentation for that is:
$ perl tools/build/pmc2c.pl --tree src/pmc/*.pmc
I thought about pasting the output into PDD 17, but decided it would
make more sense to wait until after the big PMC cleanup.
(And MultiSub really should be report that it isa Sub, at least by role
if not by inheritance.)
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?
The one thing they don't have to be currently is the same number as the
list of types in :multi (since there may be non-invocant, possibly
optional, parameters after the invocants). I'd reverse the argument and
say "can't the :multi type list be inferred from the parameter flags?"
It can with the addition KJS proposed yesterday.
Allison
