Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

suggestions for new pdd21

0 views
Skip to first unread message

Patrick R. Michaud

unread,
Jul 14, 2006, 4:02:52 PM7/14/06
to all...@cvs.perl.org, parrot-...@perl.org
Allison just updated pdd21, it looks great! Here's a first
cut at some suggested changes and wordsmithing to the text.
Feel free to adopt, ignore, or discuss any of the suggestions
below as you see fit.


: A non-nested namespace may appear in Parrot source code as the string
: C<"a"> or the key C<["a"]>.
:
: A nested namespace "b" inside the namespace "a" will appear as the key
: C<["a"; "b"]>.

Reads better if "non-nested" is removed from the first statement.

: =head2 Naming Conventions
:
: There are many different ways to implement a namespace and Parrot's target
: languages display a wide variety of them. By implementing an API and standard
: conventions, it should be possible to allow interoperability while still
: allowing each one to choose the best internal representation.

Rephrase the first sentence to:

Parrot's target languages have a wide variety of namespace models.

: Each HLL must store public items in a namespace named with the lowercased
: name of the HLL. This is the HLL root namespace. For instance, Tcl's user-
: created namespaces should live in the C<tcl> namespace. This eliminates any
: accidental collisions between languages.
:
: This namespace must be stored at the first level in parrot's namespace
: hierarchy. ...

Change "This namespace" to "An HLL root namespace" (avoid ambiguity).

: Each HLL must store implementation internals (private items) in a namespace
: named with an underscore and the lowercased name of the HLL. For instance,
: Tcl's implementation internals should live in the C<_tcl> namespace.

I think this should read

Each HLL must store implementation internals (private items) in an
HLL namespace named with an underscore and the lowercased name of
the HLL. For instance, Tcl's implementation internals should
live in the C<_tcl> HLL namespace.

: =item get_global
:
: $P1 = $P2.get_global($S3)
:
: Retrieve a global variable $P1 from the namespace $P2, with the name
: $S3.

What's the meaning of "global" in this context? Some part of me
wants this to be simply "get_symbol". Or are we contrasting "global"
with "lexical" or "private"? See also the get*_global and set*_global
opcodes below, which I think should be "get_symbol" and "set_symbol".

: =item get_name
:
: $P1 = $P2.get_name()
:
: Gets the name of the namespace $P2 as an array of strings. For example,
: if the current language is Perl 5 and the current Perl 5 namespace is
: "Some::Module" (that's Perl 5 syntax), then get_name() on that namespace
: returns an array of "perl5", "Some", "Module".

Perhaps better written as:

For example, if $P2 is the Perl 5 "Some::Module" namespace within the
Perl 5 HLL, then get_name() on $P2 returns an array of "perl5",
"Some", "Module".

: =item get_namespace
:
: $P1 = $P2.get_namespace($P3)
:
: Ask the compiler $P2 to find its namespace which is named by the
: elements of the array in $P3. Returns a namespace PMC on success and a
: null PMC on failure. A null PMC or an empty array retrieves the HLL's
: base namespace.

Swap the order of the last two sentences, thus:

Ask the compiler $P2 to find its namespace which is named by the
elements of the array in $P3. If $P3 is a null PMC or an empty
array, retrieves the base namespace for the HLL. Returns a namespace
PMC on success and a null PMC on failure.

Since this is a method, it would also be nice if $P3 could be
an optional parameter to obtain the base namespace for the HLL.

: =item load_library
:
: $P1.load_library($P2, $P3)
:
: Ask this compiler to load a library/module named by the elements of the array
: in $P2, with optional control information in $P3.
: [...]
: The meaning of $P3 is compiler-specific. The only universal legal value is
: Null, which requests a "normal" load. The meaning of "normal" varies, but
: the ideal would be to perform only the minimal actions required.

Since we have slurpy named parameters in Parrot, why not simply leave $P3
off and use (optional) named parameters here to specify options?

: =item get_global
:
: $P1 = get_global $S2
: $P1 = get_hll_global $S2
: $P1 = get_root_global $S2
:
: Retrieve the symbol named $S2 in the current namespace, HLL root
: namespace, or true root namespace.

Again, perhaps "get_symbol" might be more appropriate than
"get_global", especially since the description itself says
"Retrieve the symbol...".

Thanks,

Pm

Allison Randal

unread,
Jul 17, 2006, 12:52:35 PM7/17/06
to Patrick R. Michaud, parrot-...@perl.org
Patrick R. Michaud wrote:
> Allison just updated pdd21, it looks great! Here's a first
> cut at some suggested changes and wordsmithing to the text.
> Feel free to adopt, ignore, or discuss any of the suggestions
> below as you see fit.

Thanks, applied!

> : =item get_global
> :
> : $P1 = $P2.get_global($S3)
> :
> : Retrieve a global variable $P1 from the namespace $P2, with the name
> : $S3.
>
> What's the meaning of "global" in this context? Some part of me
> wants this to be simply "get_symbol". Or are we contrasting "global"
> with "lexical" or "private"? See also the get*_global and set*_global
> opcodes below, which I think should be "get_symbol" and "set_symbol".

I was also leaning in that direction, but the problem is that "symbol"
can also be a lexical symbol. Here we're specifically accessing symbols
from the global symbol table (the global tree of namespaces), so
"global" is the simplest way to identify it.

> ...especially since the description itself says
> "Retrieve the symbol...".

I've started using "symbol" instead of "global variable" in the
descriptions, because it's a nice generic term for named lookup (they
aren't always variables). A global variable/subroutine is a "symbol in a
namespace" and a lexical variable(/subroutine) is a "symbol in a lexical
pad".


> : =item load_library
> :
> : $P1.load_library($P2, $P3)
> :
> : Ask this compiler to load a library/module named by the elements of the array
> : in $P2, with optional control information in $P3.
> : [...]
> : The meaning of $P3 is compiler-specific. The only universal legal value is
> : Null, which requests a "normal" load. The meaning of "normal" varies, but
> : the ideal would be to perform only the minimal actions required.
>
> Since we have slurpy named parameters in Parrot, why not simply leave $P3
> off and use (optional) named parameters here to specify options?

Chip/Leo, do the various named parameter passing techniques work on
low-level PMC's defined in C?

Allison

Leopold Toetsch

unread,
Jul 17, 2006, 1:17:09 PM7/17/06
to perl6-i...@perl.org, Allison Randal, Patrick R. Michaud
Am Montag, 17. Juli 2006 18:52 schrieb Allison Randal:
> > Since we have slurpy named parameters in Parrot, why not simply leave $P3
> > off and use (optional) named parameters here to specify options?
>
> Chip/Leo, do the various named parameter passing techniques work on
> low-level PMC's defined in C?

Not yet. More specifically, we have no syntax for that, nor the tools to
create it.

A PMC method definition, e.g.

METHOD void load_library(PMC* ar, PMC* h) {...}

is processed by the PMC compiler, which generates a signature:

"vOPP" # SELF being the implicit 'O'bject

With some more annotation like:

METHOD void load_library(PMC* /**slurp**/ ar, PMC* /**namedslurp**/ h) {...}

or whatever and some perl magic, we could create signatures like:

"vI%@"

which then can be handled during argument passing.

leo

Patrick R. Michaud

unread,
Jul 17, 2006, 4:00:51 PM7/17/06
to Allison Randal, parrot-...@perl.org
On Mon, Jul 17, 2006 at 09:52:35AM -0700, Allison Randal wrote:
> >: =item get_global
> >:
> >: $P1 = $P2.get_global($S3)
> >:
> >: Retrieve a global variable $P1 from the namespace $P2, with the name
> >: $S3.
> >
> >What's the meaning of "global" in this context? Some part of me
> >wants this to be simply "get_symbol". Or are we contrasting "global"
> >with "lexical" or "private"? See also the get*_global and set*_global
> >opcodes below, which I think should be "get_symbol" and "set_symbol".
>
> I was also leaning in that direction, but the problem is that "symbol"
> can also be a lexical symbol. Here we're specifically accessing symbols
> from the global symbol table (the global tree of namespaces), so
> "global" is the simplest way to identify it.

Another possibility is to take a cue from the "find_name" opcode
(which searches lexically, in namespaces, and global) and use "get_name"
and "set_name". But now I think I'm bikeshedding this one, so I'll
be quiet.

(It would be easier to avoid bikeshedding on opcode names if Parrot
didn't already have so many naming systems to choose from. :-)

> >Since we have slurpy named parameters in Parrot, why not simply leave $P3
> >off and use (optional) named parameters here to specify options?
>
> Chip/Leo, do the various named parameter passing techniques work on
> low-level PMC's defined in C?

Oh, I had forgotten that little detail. Well, never mind. :-)

Pm

Chip Salzenberg

unread,
Jul 24, 2006, 4:16:41 PM7/24/06
to bugs-bi...@rt.perl.org
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #39927]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39927 >


On Mon, Jul 17, 2006 at 07:17:09PM +0200, Leopold Toetsch wrote:
> A PMC method definition, e.g.
> METHOD void load_library(PMC* ar, PMC* h) {...}
> is processed by the PMC compiler, which generates a signature:
> "vOPP" # SELF being the implicit 'O'bject
>
> With some more annotation like:
> METHOD void load_library(PMC* /**slurp**/ ar, PMC* /**namedslurp**/ h) {...}
> or whatever and some perl magic, we could create signatures like:
> "vI%@"
> which then can be handled during argument passing.

That would be a Good Thing.
--
Chip Salzenberg <ch...@pobox.com>

Will Coleda via RT

unread,
Jan 23, 2008, 9:12:27 PM1/23/08
to perl6-i...@perl.org
On Mon Jul 24 13:16:41 2006, chip wrote:
> On Mon, Jul 17, 2006 at 07:17:09PM +0200, Leopold Toetsch wrote:
> > A PMC method definition, e.g.
> > METHOD void load_library(PMC* ar, PMC* h) {...}
> > is processed by the PMC compiler, which generates a signature:
> > "vOPP" # SELF being the implicit 'O'bject
> >
> > With some more annotation like:
> > METHOD void load_library(PMC* /**slurp**/ ar, PMC*
> /**namedslurp**/ h) {...}
> > or whatever and some perl magic, we could create signatures like:
> > "vI%@"
> > which then can be handled during argument passing.
>
> That would be a Good Thing.

Unless I'm mistaken, these are covered by PCCMETHOD (for some time now). Unless I hear a
squawk, I'll close this out as implemented in a few days.

0 new messages