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
