develooper Front page | perl.perl6.language | Postings from March 2005

Re: MMD as an object.

Thread Previous | Thread Next
From:
Bob Rogers
Date:
March 11, 2005 00:43
Subject:
Re: MMD as an object.
Message ID:
16945.3921.550301.73149@rgrjr.dyndns.org
   From: Leopold Toetsch <lt@toetsch.at>
   Date: Thu, 10 Mar 2005 10:53:11 +0100

   Rod Adams <rod@rodadams.net> wrote:
   > It seems to me that there are several advantages to making a group of
   > multi with the same short name a single object, of type
   > MultiSub|MultiMethod, which internally holds references to the all the
   > various routines that share that short name.

   Discussion seems to have went off into esoteric cases of locally
   overriden dispatcher policies and what not.

   What I'd like to know is more basic things:

   1) is there a MultiSub object with one short name that holds all
   possible long names (and function references)?
   If yes, who is creating it: the Perl6 compiler emits code to do so or
   it's up to Parrot to do the right thing?

FWIW, Common Lisp specifies a "generic function" [1] that collects all
methods defined for a given operation name.  (In Perl/Parrot, the
generic function name for your examples would be the string "foo"; in
Lisp, it would be the symbol "FOO" in some package, but the practical
difference should be slight.)  The important thing is that the GF has
all the information required to make method dispatch decisions.

   GFs can be created explicitly with defgeneric [2], or implicitly by
defining methods.  According to that model, the Perl6 compiler would
emit code for each method, and ask Parrot to add it to the appropriate
MMD object, which may cause effective methods to be recomputed (or be
marked as invalid for lazy recomputation).

   Mind you, I haven't read up on p6 objects, so my $0.02 might not be
worth very much.  If so, please rub my nose in the relevant apocalypses,
etc., and I'll shut up.  But on the other hand, the CL community has
more than 15 years of experience with MMD, so I wanted to be sure
everyone was aware of it.

   2) namespaces of (multi) subs.

   A non-multi method is in the classes' namespace. In Parrot terms that's
   currently:

     %globals{"\0class_name"}{"method_name"}

   I'm not quite sure, if the method hash shouldn't live inside the class.

Is naming at this level really important here?  The operation itself
needs a name (so that people can call it), and classes need class names
(maybe), but all methods are implicitly named by the combination of
operation plus argument signature.  Which would seem to mean that,
unlike perl5, the package in which a multimethod is defined doesn't
matter; all that is captured by the argument signature.  Or is it
possible to have more than one method with the identical signature?  And
if so, what does that mean?

   The "long name" is therefore a list of class names, which suggests
that the single-dispatch naming above is backwards.  Of course, I'm
probably out of my depth here . . .

   A multi method is similar, except that their can be more then one
   with the same short name (which probably means that there has to be a
   MultiSub object holding the long names)

I'm not sure it is meaningful to give a sub a "short name," certainly
not in the sense that perl5 methods can also be called as subs with the
right package qualification.  You can't guarantee that they will be
unique, correct?

   What about multi subs? They can be defined everywhere. Given:

     multi sub *foo(A $a, B $b) {...}

   Is this something like:

     %globals{"foo"}  -->  MultiSub{"foo_A_B" => Sub, ...}

This sounds right to me.  Or perhaps

	%globals{"foo"}  -->  MultiSub{["foo", 'A', 'B'] => Sub, ...}

just to belabor the point a bit.

   What about a not so global multi:

     multi sub foo(A $a, B $b) {...}

   Thanks for clarifying,
   leo

Is this really different?  After all, the operation "foo" should be just
a string in either case.  Or is this just my ignorance showing?

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

[1] http://www.lispworks.com/documentation/HyperSpec/Body/t_generi.htm

[2] http://www.lispworks.com/documentation/HyperSpec/Body/m_defgen.htm#defgeneric

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About