Re: suggestions for new pdd21

[Allison Randal]

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

Re: suggestions for new pdd21

[Leopold Toetsch]

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

Re: suggestions for new pdd21

[Patrick R. Michaud]

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

suggestions for new pdd21

[Patrick R. Michaud]

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
: Ca 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 Ctcl 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