Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Bob Rogers wrote: My sense of the usage on this list is that multisub means a MultiSub PMC and a multimethod is what you add to the MultiSub when you define a sub with the :multi keyword. Am I the only one who finds this a useful distinction? Oh, I see. No wonder this conversation has been confusing. If multisub and multimethod are to be used at all, a multisub is a MultiSub PMC when it's invoked as a sub, and a multimethod is a MultiSub PMC when it's invoked as a method (marked as ':multi :method'). Then a multivtable would be a MultiSub PMC invoked as a vtable function (marked as ':multi :vtable'). A particular sub object that's stored in a MultiSub is a variant of the multi (whether it's a multisub, multimethod, or multivtable). Allison
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED] Date: Sat, 30 Aug 2008 11:56:45 +0200 Bob Rogers wrote: My sense of the usage on this list is that multisub means a MultiSub PMC and a multimethod is what you add to the MultiSub when you define a sub with the :multi keyword. Am I the only one who finds this a useful distinction? Oh, I see. No wonder this conversation has been confusing. The mistake, I think, is when we assume that we speak the same language. ;-} To everyone else: From the lack of other response, should I assume that my memory of this usage of multimethod for sub with :multi is incorrect? . . . A particular sub object that's stored in a MultiSub is a variant of the multi (whether it's a multisub, multimethod, or multivtable). Allison Urp. I have been calling these methods for 15 or 20 years now (since whenever the Lisp world went to MMD), so please bear with me while I change gears. FWIW, the documentation has about 100 hits to the word variant, but only two (AFAICS) refer to MMD, both of them in a single paragraph in docs/book/ch07_architecture.pod. The other hits are talking about opcodes and vtable operations. (Plus a hit I don't understand in docs/pdds/pdd15_object_metamodel.svg, which doesn't seem to address MMD at all.) -- Bob
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Bob Rogers wrote: Just single dispatch. A method that's single dispatched, is... a method. True. Nevertheless, the two kinds of method are treated quite differently by Parrot, both when being defined and when being called. That is why it is awkward not to have concise names for both kinds. We have vtable functions, subs, methods, and multis. A multi is neither a sub nor a method nor a vtable function, though it may substitute for any of them. Allison
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED] Date: Fri, 29 Aug 2008 11:19:37 +0200 Bob Rogers wrote: Just single dispatch. A method that's single dispatched, is... a method. True. Nevertheless, the two kinds of method are treated quite differently by Parrot, both when being defined and when being called. That is why it is awkward not to have concise names for both kinds. We have vtable functions, subs, methods, and multis. So you prefer the plain term method for method that is not a multimethod? That seems prone to confusion. What do you suggest for the generic term? A multi is neither a sub nor a method nor a vtable function, though it may substitute for any of them. Allison By multi do you mean multisub or multimethod? Either way, it seems there is something missing from your enumeration above. -- Bob
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Bob Rogers wrote: So you prefer the plain term method for method that is not a multimethod? That seems prone to confusion. What do you suggest for the generic term? It's not prone to confusion. By definition, a method is a invoked on a single invocant (an instance of the class that contains the method). By multi do you mean multisub or multimethod? Either way, it seems there is something missing from your enumeration above. A multi (that is a MultiSub PMC) can be invoked as either a sub or a method. There is no distinction between a multisub and a multimethod. There are only multis, which are dispatched based on an evaluation of multiple invocants. Allison
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED] Date: Fri, 29 Aug 2008 16:03:24 +0200 Bob Rogers wrote: By multi do you mean multisub or multimethod? Either way, it seems there is something missing from your enumeration above. A multi (that is a MultiSub PMC) can be invoked as either a sub or a method. There is no distinction between a multisub and a multimethod. There are only multis, which are dispatched based on an evaluation of multiple invocants. Allison My sense of the usage on this list is that multisub means a MultiSub PMC and a multimethod is what you add to the MultiSub when you define a sub with the :multi keyword. Am I the only one who finds this a useful distinction? -- Bob
[svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Author: allison
Date: Thu Aug 28 09:09:48 2008
New Revision: 30620
Added:
trunk/docs/pdds/draft/pdd31_hll_interop.pod
Log:
[pdd] Adding an early draft PDD for HLL interoperability, from Bob Rogers.
Added: trunk/docs/pdds/draft/pdd31_hll_interop.pod
==
--- (empty file)
+++ trunk/docs/pdds/draft/pdd31_hll_interop.pod Thu Aug 28 09:09:48 2008
@@ -0,0 +1,466 @@
+# Copyright (C) 2008, The Perl Foundation.
+# $Id: $
+
+=head1 NAME
+
+docs/pdds/pddxx_language_interop.pod - Inter-language calling
+
+=head1 VERSION
+
+$Revision: 28231 $
+
+=head1 ABSTRACT
+
+This PDD describes Parrot's conventions and support for communication between
+high-level languages (HLLs). It is focused mostly on what implementors should
+do in order to provide this capability to their users.
+
+=head1 DESCRIPTION
+
+The ability to mix different high-level languages at runtime has always been
+an important design goal of Parrot. Another important goal, that of
+supporting all dynamic languages, makes language interoperability especially
+interesting -- where interesting means the same as it does in the Chinese
+curse, May you live in interesting times. It is expected that language
+implementers, package authors, and package users will have to be aware of
+language boundaries when writing their code. It is hoped that this will not
+become too burdensome.
+
+None of what follows is binding on language implementors, who may do whatever
+they please. Nevertheless, we hope they will at least follow the spirit of
+this document so that the code they produce can be used by the rest of the
+Parrot community, and save the fancy footwork for intra-language calling.
+However, this PDD Bis binding on Parrot implementors, who must provide a
+stable platform for language interoperability to the language implementors.
+
+=head2 Ground rules
+
+In order to avoid N**2 complexity and the resulting coordination headaches,
+each language compiler provides an interface as a target for other languages
+that should be designed to require a minimum of translation. In the general
+case, some translation may be required by both the calling language and the
+called language:
+
+|
+ |
+|Calling sub
+| |
+| Language X|
+| V
+|Calling stub
++ |
+ |
+ plain Parrot |
+ |
++ |
+|V
+| Called wrapper
+| |
+| |
+| Language YV
+| Called sub
+ |
+
+Where necessary, a language may need to provide a wrapper sub to interface
+external calls to the language's internal calling and data representation
+requirements. Such wrappers are free to do whatever translation is required.
+
+Similarly, the caller may need to emit a stub that converts an internal call
+into something more generic.
+
+{{ Of course, stub is really too close to sub, so we should find a better
+word. Doesn't the C community call these bounce routines? Or something?
+-- rgr, 31-Jul-08. }}
+
+{{ I am discovering that there are five different viewpoints here,
+corresponding to the five layers (including plain Parrot) of the diagram
+above. I need to make these viewpoints clearer, and describe the
+responsibilities of each of these parties to each other. -- rgr,
+31-Jul-08. }}
+
+Languages are free to implement the stub and wrapper layers (collectively
+called glue) as they see fit. In particular, they may be inlined in the
+caller, or integral to the callee.
+
+Ideally, of course, the plain Parrot layer will be close enough to the
+semantics of both languages that glue code is unnecesary, and the call can be
+made directly. Language implementors are encouraged to dispense with glue
+whenever possible, even if glue is sometimes required for the general case.
+
+In summary:
+
+=over 4
+
+=item *
+
+Each HLL gets its own namespace subtree, within which Cget_hll_global and
+Cset_hll_global operate. In order to make external calls, the HLL must
+provide a means of identifying the language, the function, and enough
+information about the arguments and return values for the calling language to
+generate the call correctly. This is necessarily language-dependent, and is
+beyond the scope of this document.
+
+=item *
+
+When calling across languages, both the caller and the callee should try to
+use plain Parrot semantics to the extent possible. This is explained in
+more detail below, but essentially means to use the simplest calling
+conventions and PMC classes possible.
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
[EMAIL PROTECTED] wrote:
+{{ Is the term unimethod acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is single dispatch, and unimethod
could thus be single method.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
Moritz Lenz wrote:
[EMAIL PROTECTED] wrote:
+{{ Is the term unimethod acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is single dispatch, and unimethod
could thus be single method.
Just single dispatch. A method that's single dispatched, is... a method.
Allison
Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED]
Date: Thu, 28 Aug 2008 22:14:08 +0200
Moritz Lenz wrote:
[EMAIL PROTECTED] wrote:
+{{ Is the term unimethod acceptable here? -- rgr, 29-Jul-08. }}
I think for dispatch the term is single dispatch, and unimethod
could thus be single method.
Just single dispatch. A method that's single dispatched, is... a method.
Allison
True. Nevertheless, the two kinds of method are treated quite
differently by Parrot, both when being defined and when being called.
That is why it is awkward not to have concise names for both kinds.
-- Bob
