test of get_namespace opcode vs. arrays
Chip Salzenberg
> Another FAILING namespace test:
> $P0 = new .ResizableStringArray
> $P0[0] = ''
> $P1 = get_namespace $P0
I think I (or the pdd) may have been misunderstood:
The get_namespace opcode currently accepts keys (and strings).
The compiler.'get_namespace'() method accepts arrays.
So unless I've missed something in the purpose of your test, it's testing
behavior that Parrot isn't trying to provide.
--
Chip Salzenberg <ch...@pobox.com>
Matt Diephouse
At the top of the pdd:
- Add a get_namespace opcode (that takes an -->array<-- or a multidimensional
hash index)
A bit further down:
=item $P0 = get_namespace $P1
=item $P0 = get_namespace
Get the namespace $P1 (an -->array<-- of names or a
multidimensional hash index) or
the current namespace. To get the "Foo::Bar" namespace, one would use this:
$P0 = split "::", "Foo::Bar"
$P1 = get_namespace $P0
It's definitely in the pdd; even the example here uses arrays (not too
surprising, since I wrote it. ;-). Arrays are the easiest way to be
able to get a namespace at runtime... which translates to the easiest
way for Tcl to use namespaces.
--
matt diephouse
http://matt.diephouse.com
Chip Salzenberg
> At the top of the pdd:
> - Add a get_namespace opcode (that takes an -->array<-- or a
> multidimensional hash index)
> =item $P0 = get_namespace $P1
>
Gee, you're right, there it is, and strangely enough, the code already
supports this idiom [leo++]. I've just gone through the doc and made it
more consistent on that point.
The actual bug you've found seems unrelated to the use of the array of
strings (vs. a key), as substituting the key version:
$P0 = get_namespace ['']
still fails. Debugging in progress.
--
Chip Salzenberg <ch...@pobox.com>
Matt Diephouse
> The actual bug you've found seems unrelated to the use of the array of
> strings (vs. a key), as substituting the key version:
>
> $P0 = get_namespace ['']
>
> still fails. Debugging in progress.
It looks like IMCC treats C< .namespace [''] > as the root HLL
namespace (and not as the namespace '' inside of that). So that's
where the bug really lies.
mini:~/Projects/parrot mdiep$ cat test.pir
.namespace ['']
.sub main :main
$P0 = get_namespace
$P0 = $P0.'name'()
$S0 = join "::", $P0
print $S0
print "\n"
end
.end
mini:~/Projects/parrot mdiep$ parrot test.pir
parrot
mini:~/Projects/parrot mdiep$
Chip Salzenberg
> Chip Salzenberg <ch...@pobox.com> wrote:
> >The actual bug you've found seems unrelated to the use of the array of
> >strings (vs. a key), as substituting the key version:
> > $P0 = get_namespace ['']
> >still fails. Debugging in progress.
>
> It looks like IMCC treats C< .namespace [''] > as the root HLL
> namespace (and not as the namespace '' inside of that). So that's
> where the bug really lies.
I've rooted out that bug, but then discovered there's no way left to
designate the root HLL namespace, so I've invented
.namespace # no key
to mean the HLL root.
Now it's a matter of making the tests all work (again). :-)
--
Chip Salzenberg <ch...@pobox.com>
Matt Diephouse
> I've rooted out that bug, but then discovered there's no way left to
> designate the root HLL namespace, so I've invented
> .namespace # no key
> to mean the HLL root.
That resolves the other ticket I opened yesterday (good). But I'd
prefer to have C< .namespace [] > so that we could also have the
matching C< find_global [], 'foo' >. Otherwise find_global becomes a
two step operation for finding globals in the root HLL namespace.
Oh, and I've committed some more failing tests. :-)
Chip Salzenberg
> Chip Salzenberg <ch...@pobox.com> wrote:
> >means the HLL root.
>
> That resolves the other ticket I opened yesterday (good). But I'd
> prefer to have C< .namespace [] > so that we could also have the
> matching C< find_global [], 'foo' >. Otherwise find_global becomes a
> two step operation for finding globals in the root HLL namespace.
Well, that's a bit problematic. The [] syntax is inherited from the key
syntax, and keys currently can't be empty. The use of keys is a hack, but
it's a very convenient hack at the source code level, and unlikely to
change.
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys. And this makes keys even more compatible with the
Array interface, which I think they might need to implement someday anyway.
Allison, what do you think of zero-length keys, i.e. having [] construct a
Key PMC describing no dimensions of lookup? If we use those we can get rid
of the current null-string hack.
If zero-length keys are not OK, then...
--- PART 3, IN WHICH AN UGLY BUT WORKING HACK IS DESCRIBED --
I introduced a hack in my recent namespace cleanups. I was planning to
ask/warn users about it, but then forgot I'd done it, so it's in the svn
repo now. The hack is:
When find_global or store_global expects a string or PMC to designate (name)
a namespace, Parrot takes a null value to name the HLL root namespace.
Thus:
.sub main :main
$P0 = find_global 'Foo', 'bar'
$P0()
.end
.sub bar
.end
.namespace ['Foo']
.sub bar
$P0 = find_global 'bar' # ['parrot';'Foo';'bar']
null $S0
$P1 = find_global $S0, 'bar' # ['parrot';'bar']
.end
I don't recommend anyone coding anything to use this feature, because the
more I look at it the less I like it: It's still a two-step process, and
with kludge factor to boot. Zero-length keys are better, IMO.
--
Chip Salzenberg <ch...@pobox.com>
Allison Randal
>
> --- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
>
> On the other hand, we could extend the key PMC to represent emptiness,
> i.e. zero dimensions. This seems useful for namespaces and could even prove
> useful for real keys. And this makes keys even more compatible with the
> Array interface, which I think they might need to implement someday anyway.
>
> Allison, what do you think of zero-length keys, i.e. having [] construct a
> Key PMC describing no dimensions of lookup? If we use those we can get rid
> of the current null-string hack.
Fundamentally altering the way keyed access works seems like a pretty
extreme solution when the problem is just "the root HLL namespace
doesn't have a name". (Actually, it does have a name: 'parrot', 'tcl',
'perl6', etc. A sort of "key who must not be named", if I won't be shot
for making terrible Harry Potter references at 1am.)
It's simpler to give the root HLL namespace a name.
> If zero-length keys are not OK, then...
>
> --- PART 3, IN WHICH AN UGLY BUT WORKING HACK IS DESCRIBED --
>
> I introduced a hack in my recent namespace cleanups. I was planning to
> ask/warn users about it, but then forgot I'd done it, so it's in the svn
> repo now. The hack is:
>
> When find_global or store_global expects a string or PMC to designate (name)
> a namespace, Parrot takes a null value to name the HLL root namespace.
A null string could be canonized as the "name" of the root namespace,
though something a little more meaningful and easier to type would be nice.
The problem is really that we're trying to simultaneously a) refer to
the root HLL namespace directly, and b) pretend that it doesn't exist.
I had a much longer reply, but I'm going to let it steep overnight and
see what percolates.
Allison
Chip Salzenberg
> The problem is really that we're trying to simultaneously a) refer to
> the root HLL namespace directly, and b) pretend that it doesn't exist.
I don't think (b) is quite true. It's more that we're avoiding explicit
re-coding of a known bit of environmental information, as in "the first
floor of this building" rather than "the first floor of 123 main street".
> Chip Salzenberg wrote:
> >Allison, what do you think of zero-length keys, i.e. having [] construct a
> >Key PMC describing no dimensions of lookup? If we use those we can get rid
> >of the current null-string hack.
>
> Fundamentally altering the way keyed access works seems like a pretty
> extreme solution when the problem is just "the root HLL namespace
> doesn't have a name".
I brought it up partly because I was hoping you'd say something like, "Oh
yeah, we're gonna need zero-length keys anyway for Perl 6". What is the
parameter to operator:postcircumfix [] when a user says
@array.[]
?
> It's simpler to give the root HLL namespace a name.
Indeed, it already has the name of "empty list" when a PMC array is the
naming vehicle:
$P0 = new .FixedPMCArray
$P1 = get_namespace $P0 # that's the HLL root
There are two kinds of lists in play for namespaces; one of them can have a
length of zero (PMC array), but the other one can't (key), and the one that
can be zero-length doesn't have convenience pasm syntax.
> A null string could be canonized as the "name" of the root namespace,
> though something a little more meaningful and easier to type would be nice.
I should emphasize that I've gone to the recent trouble of making namespace
[''] *not* mean the HLL root for two reasons: (1) it's poor manners on the
part of a VM to steal names from HLLs or users, and (2) when a user is
working with an array of names, they'll want to be able to decompose the
list -- which puts a string that used to be in the middle out on the front,
or by itself -- without accidentally re-rooting the search.
Possibility: If we introduce a pasm keyword Null to mean a pmc constant null
(and perhaps a string contant null), then the null name could be easier to
type. It could also be useful in other contexts.
Gentle observation: [] is pretty easy to type, and offers consistency:
$P2 = get_namespace ['a','b'] # two levels from root
$P1 = get_namespace ['a'] # one level from root
$P0 = get_namespace [] # zero levels from root
Ugly hack / joke: If you were willing to look the other way, [] could be an
alternative spelling for PMC Null. :-P
--
Chip Salzenberg <ch...@pobox.com>
Allison Randal
>
> I had a much longer reply, but I'm going to let it steep overnight and
> see what percolates.
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully specified namespace, including the HLL namespace.
$P0 = find_global 'bar' # the top-level namespace
$P1 = find_global 'parrot', 'bar' # 'bar' in ['parrot']
$P2 = find_global ['parrot';'Foo'], 'bar' # 'bar' in ['parrot';'Foo']
$P3 = find_global 'tcl', 'bar' # 'bar' in ['tcl']
Then a set of opcodes using the add_*, del_*, get_* naming scheme handle
the "magically assume the HLL root/current namespace" behavior. (PDD 21
uses both get_* and find_* for retrieval. It's better to standardize on
one, but it doesn't really matter which one.)
.HLL "Perl5", "perl5_group"
$P0 = get_symbol 'bar' # 'bar' in ['perl5']
$P1 = get_symbol 'Foo', 'bar' # 'bar in ['perl5';'Foo']
.namespace [ 'Foo' ]
$P2 = get_symbol 'bar' # 'bar' in ['perl5';'Foo']
(I thought about prefixing all the opcodes that assume the HLL namespace
with hll_, but since those are the common case, I'd rather mark the
rarer global case.)
The .namespace directive has more flexibility, since it's a directive
not an opcode. We can keep the basic syntax as the magical HLL behavior:
.namespace [ 'Foo' ] # namespace is ['parrot';'Foo']
.HLL "Perl5", "perl5_group" # namespace is ['perl5']
.namespace [ 'Foo' ] # namespace is ['perl5';'Foo']
If you only use .HLL and no .namespace, then it assumes the root HLL
namespace.
And add a couple of special forms for the rarer cases when you want to
set the current namespace to the HLL or global root:
.namespace hll_root
.namespace global_root
------
Here are some of the "also-ran"s, in abbreviated form:
--
We could take the Perl 5 strategy of reserving a name ('main' or 'root'
or something similar) to always act as an alias to the top-level of the
current HLL namespace.
Conclusion: Perl 5 on Parrot will use this strategy, and so might other
languages, but we shouldn't force it on all languages.
--
We could break out the root prefix from the rest of the name:
$P2 = find_global 'parrot', ['Foo'], 'bar' # bar in ['parrot';'Foo']
Conclusion: reaching the global root would require an empty prefix key
and an empty namespace name key. Not really an improvement, more of an
unprovement.
--
We could have separate opcodes for "direct access" and "hll indirect
access".
Conclusion: this led to a combinatorial explosion (bad), but then to the
simplified solution above.
--
We could assume the current HLL namespace, and call methods on the
namespace object to retrieve "meta" information like the root HLL
namespace or global namespace.
Conclusion: more complex than is necessary to solve the problem.
------
Allison
Allison Randal
> On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote:
>> The problem is really that we're trying to simultaneously a) refer to
>> the root HLL namespace directly, and b) pretend that it doesn't exist.
>
> I don't think (b) is quite true. It's more that we're avoiding explicit
> re-coding of a known bit of environmental information, as in "the first
> floor of this building" rather than "the first floor of 123 main street".
That's another good way of phrasing it. It's essentially the linguistic
problem of being able to refer to something both by its full name and by
the pronoun "it". (Otherwise known as "topic".) Only, currently "it"
isn't represented by a word. There are natural languages with
zero-length pronouns, but they generally compensate by marking the verb
with enough information to disambiguate. And when that gets unclear,
they throw in the full name again.
> ...I was hoping you'd say something like, "Oh
> yeah, we're gonna need zero-length keys anyway for Perl 6". What is the
> parameter to operator:postcircumfix [] when a user says
>
> @array.[]
>
> ?
Various HLLs will assign some meaning to a null key. But the semantics
of this isn't keyed access. The HLL is just using a bit of unused syntax
to mean "return an empty list", or "return null", or "return all the
elements of the array as a list", or whatever else they decide to use it
for. It's up to the HLL compiler to distill the syntax down to
meaningful semantics.
Allison
Chip Salzenberg
> It's essentially the linguistic problem of being able to refer to
> something both by its full name and by the pronoun "it". (Otherwise known
> as "topic".) Only, currently "it" isn't represented by a word.
Well, we have three distinct 'it's for namespaces: the Parrot root, the HLL
root, and the current.
I view the HLL root as the main one for most purposes, and escaping the HLL
root I model as escaping a Unix chroot (in rarity if not security), which is
why I'm conformable with using interpinfo to get the global root. And of
course the current namespace maps onto the Unix working dir for me.
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
that I'll be providing as easy a transition as possible when/if these global
opcodes are adjusted. }
On Thu, Jul 06, 2006 at 11:53:59AM -0700, Allison Randal wrote:
> I ran through a number of possibilities, but so far my favorite is:
> find_global and store_global are truly 'global', that is, they always
> require a fully specified namespace, including the HLL namespace.
>
> Then a set of opcodes using the add_*, del_*, get_* naming scheme handle
> the "magically assume the HLL root/current namespace" behavior. (PDD 21
> uses both get_* and find_* for retrieval. It's better to standardize on
> one, but it doesn't really matter which one.)
Well, I see a lot to like about this, but (and you knew there was a "but"
("but" that's my job now :-))), in descending order of difficulty:
* The division into two categories ("global" and "symbol") leaves the third
category (current namespace) with no clear home.
* All the things being accessed are globals. Seems like the word "global"
should be used consistently, and "symbol" has many meanings in Parrot
that only partly overlap the specific meaning of "global".
* We still don't have way to ask for "my HLL" without spelling it. I can
say "my HLL's Foo" without spelling my HLL, but when I go up to my HLL's
root I must suddenly know the spelling of my HLL and say it. Seems like
a sign of a design problem.
* The global root is available as C<interpinfo .INTERPINFO_ROOT_NAMESPACE>
at present -- awkward but fast. Since global root accesses are supposed
to be rare, awkwardness doesn't bug me for that case. But adding opcodes
for absolute-root ... hey, "absolute", that's a good name.
* Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
most languages. Most PIR/pasm is program-generated.
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_global 'x' # ['perl5';'x']
$P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
(If there is no Null, substitute a null PMC register.)
--
Chip Salzenberg <ch...@pobox.com>
Jerry Gay
> So here's an illustrative suggestion, which I think is a variant on one of
> your also-rans, albeit one that leaves the common HLL case unmarked:
>
> .HLL 'perl5', perl5_group
> .namespace ['Foo']
>
> $P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
> $P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
>
namespace, they're just as likely to be found closer to the namespace
root, than further away? perhaps something like
.namespace [ 'Foo'; 'Bar' ]
$P0 = get_cur_global -1, 'x' # [ 'perl5' ; 'Foo' ; 'x' ]
i don't see any examples that make it easy to look in that direction.
~jerry
Matt Diephouse
> Chip Salzenberg wrote:
> >
> > --- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
> >
> > On the other hand, we could extend the key PMC to represent emptiness,
> > i.e. zero dimensions. This seems useful for namespaces and could even prove
> > useful for real keys. And this makes keys even more compatible with the
> > Array interface, which I think they might need to implement someday anyway.
> >
> > Allison, what do you think of zero-length keys, i.e. having [] construct a
> > Key PMC describing no dimensions of lookup? If we use those we can get rid
> > of the current null-string hack.
>
> Fundamentally altering the way keyed access works seems like a pretty
> extreme solution when the problem is just "the root HLL namespace
> doesn't have a name". (Actually, it does have a name: 'parrot', 'tcl',
> 'perl6', etc. A sort of "key who must not be named", if I won't be shot
> for making terrible Harry Potter references at 1am.)
I don't think "fundamentally altering the way keyed access works" is a
fair description of what Chip proposed (and what I was asking for).
0-dimensional keys seem like a logical extension to multi-dimensional
keys, IMO.
Chip actually forgot that there is another way to get to the root HLL
namespace besides using the null string hack:
$P0 = new .ResizablePMCArray # this can be any array type
$P1 = get_namespace $P0
But arrays fill a different niche than keys do. Arrays are a runtime
solution and keys are a compile time solution. Writing out arrays when
you're writing code is painful and making keys at runtime is
impossible AFAICT.
So for the runtime (this is the HLL runtime, not the PIR runtime, btw)
we're all set. Arrays fill the need perfectly and let us access the
root HLL namespace. That makes me think that we don't need any new
opcodes.
It's just the compile time time -- the code that humans actually have
to write -- that is giving us trouble. That's a bit of a
simplification because in many cases compiler writers can optimize the
code and use keyed access in the output code, but it's just as simple
in that case to use any old hack.
That's why I was asking for C< $P0 = get_namespace [] > -- because I
actually have to write it. And I think it's a worthy goal to make
compiler writer's lives good.
Adding 0-dimensional keys would also let us get rid of the C<
.namespace > special case and replace it with C< .namespace [] >.
> It's simpler to give the root HLL namespace a name.
I disagree on two counts here. First, I think C< [] > *is* a name.
Second, any solution which involves giving the HLL namespace a
different name will have to either (a) add new opcodes, (b) add more
code for all the other cases by making all referencing originate at
the root, or (c) add a special syntax, none of which is simple.
Allison Randal
>
> Well, I see a lot to like about this, but (and you knew there was a "but"
> ("but" that's my job now :-))), in descending order of difficulty:
And you do it so well. Thank you. :)
> * The division into two categories ("global" and "symbol") leaves the third
> category (current namespace) with no clear home.
Agreed.
> * All the things being accessed are globals. Seems like the word "global"
> should be used consistently, and "symbol" has many meanings in Parrot
> that only partly overlap the specific meaning of "global".
Agreed.
> * We still don't have way to ask for "my HLL" without spelling it. I can
> say "my HLL's Foo" without spelling my HLL, but when I go up to my HLL's
> root I must suddenly know the spelling of my HLL and say it. Seems like
> a sign of a design problem.
Agreed.
> * The global root is available as C<interpinfo .INTERPINFO_ROOT_NAMESPACE>
> at present -- awkward but fast. Since global root accesses are supposed
> to be rare, awkwardness doesn't bug me for that case. But adding opcodes
> for absolute-root ... hey, "absolute", that's a good name.
>
> * Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
> most languages. Most PIR/pasm is program-generated.
Agreed, with a note of balance that we also want to avoid the pain of
XS. Sometimes you need to poke into the guts of the system, and when you
do, you want it to be pleasant to work with, even though it's not fancy.
> So here's an illustrative suggestion, which I think is a variant on one of
> your also-rans, albeit one that leaves the common HLL case unmarked:
>
> .HLL 'perl5', perl5_group
> .namespace ['Foo']
>
> $P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
> $P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
>
> $P0 = get_global 'x' # ['perl5';'x']
> $P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
>
> $P0 = get_abs_global 'x' # ['x']
> $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
This is non-evil. :)
I would rename 'get_cur_global' to 'get_global'. The selected namespace
indicates that most of the code belongs in that namespace, so it's
likely that most of the variables do too. (There are variations, but
that's at least the common case.)
Then, what to call the HLL root access opcodes... perhaps
'get_rel_global' (for relative root)?
Allison
Allison Randal
>
> So for the runtime (this is the HLL runtime, not the PIR runtime, btw)
> we're all set. Arrays fill the need perfectly and let us access the
> root HLL namespace. That makes me think that we don't need any new
> opcodes.
Chip's latest simplification eliminates the need for creating and
passing in an empty array, because 'no argument' always means the same
thing as 'empty array' or 'no key' would mean. That's a really elegant
piece of consistency.
> And I think it's a worthy goal to make
> compiler writer's lives good.
I agree.
> Adding 0-dimensional keys would also let us get rid of the C<
> .namespace > special case and replace it with C< .namespace [] >.
Hmmm... if we're preserving parallels, that could be C< $P0 =
get_namespace > and C< .namespace >
>> It's simpler to give the root HLL namespace a name.
>
> I disagree on two counts here.
And I've moved on to "the root HLL namespace doesn't need a name if you
disambiguate by marking the verb (that is, the opcode)."
> First, I think C< [] > *is* a name.
Yes, in using C< [] > to mean "access the root HLL namespace" we would
be treating it as a name. Or more like a method call. It's a magical bit
of syntax that would be appropriate in a HLL, but seems out-of-place in PIR.
> Second, any solution which involves giving the HLL namespace a
> different name will have to either (a) add new opcodes, (b) add more
> code for all the other cases by making all referencing originate at
> the root, or (c) add a special syntax, none of which is simple.
To add a new feature, we have to add some extra syntax somewhere. I'm
most comfortable with (a) here, because it targets the change at the
problem in a straightforward fashion.
Allison
Chip Salzenberg
> am i silly to think that if i'm looking for globals from the current
> namespace, they're just as likely to be found closer to the namespace
> root, than further away? perhaps something like
>
> .namespace [ 'Foo'; 'Bar' ]
> $P0 = get_cur_global -1, 'x' # [ 'perl5' ; 'Foo' ; 'x' ]
There's a technical reason for this omission.
The only way to get to namespace '..' (using the Unix analogy) is to ask the
namespace for its parent, and I don't want to do that. Given the presence of
namespace aliasing, a namespace isn't guaranteed to have a single parent, or
that that parent will be the one it was, er, born with.
The compiler knows the full name and it's easy enough for the compiler to
strip the last element off the namespace path.
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
found. (particle++ for the finding) }
On Fri, Jul 07, 2006 at 12:46:35AM -0700, Allison Randal wrote:
> Chip Salzenberg wrote:
> >Well, I see a lot to like about this, but (and you knew there was a "but"
> >("but" that's my job now :-))), in descending order of difficulty:
>
> And you do it so well. Thank you. :)
Always a pleasure.
> > * Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
> > most languages. Most PIR/pasm is program-generated.
>
> Agreed, with a note of balance that we also want to avoid the pain of
> XS. Sometimes you need to poke into the guts of the system, and when you
> do, you want it to be pleasant to work with, even though it's not fancy.
Point well taken. Pain is acceptable but not a goal.
> >So here's an illustrative suggestion, which I think is a variant on one of
> >your also-rans, albeit one that leaves the common HLL case unmarked:
> >
> > .HLL 'perl5', perl5_group
> > .namespace ['Foo']
> >
> > $P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
> > $P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
> >
> > $P0 = get_global 'x' # ['perl5';'x']
> > $P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
> >
> > $P0 = get_abs_global 'x' # ['x']
> > $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
>
> This is non-evil. :)
<grin/>
> I would rename 'get_cur_global' to 'get_global'. The selected namespace
> indicates that most of the code belongs in that namespace, so it's
> likely that most of the variables do too. (There are variations, but
> that's at least the common case.)
Works for me. And that is the current meaning of two-parameter find_global,
so it's not a stretch.
> Then, what to call the HLL root access opcodes... perhaps 'get_rel_global'
> (for relative root)?
Hrm. Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that "hll" is the
best I can think of, and given the existing ".HLL" directive, its meaning
is immediately clear:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_global 'x' # ['perl5';'Foo';'x']
$P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_hll_global 'x' # ['perl5';'x']
$P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
Seems to me that we should have get_namespace patterned just alike:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_namespace # ['perl5';'Foo']
$P0 = get_namespace ['Bar'] # ['perl5';'Foo';'Bar']
$P0 = get_hll_namespace # ['perl5']
$P0 = get_hll_namespace ['Corge'] # ['perl5';'Corge']
$P0 = get_abs_namespace # [] :-)
$P0 = get_abs_namespace ['parrot'] # ['parrot']
I'm still not entirely happy with "abs", but I can live with it, especially
since its use should be quite rare.
--
Chip Salzenberg <ch...@pobox.com>
Matt Diephouse
> { Language implementors, please know I'm going to do everything I can to
> make every commit break nothing. I did pretty well when I made namespace
> [''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
> two bits of code generation in TGE and PGE, which I fixed when they were
> found. (particle++ for the finding) }
chip++ :-)
> On Fri, Jul 07, 2006 at 12:46:35AM -0700, Allison Randal wrote:
> > Chip Salzenberg wrote:
> > > * Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
> > > most languages. Most PIR/pasm is program-generated.
> >
> > Agreed, with a note of balance that we also want to avoid the pain of
> > XS. Sometimes you need to poke into the guts of the system, and when you
> > do, you want it to be pleasant to work with, even though it's not fancy.
>
> Point well taken. Pain is acceptable but not a goal.
Good points.
> > >So here's an illustrative suggestion, which I think is a variant on one of
> > >your also-rans, albeit one that leaves the common HLL case unmarked:
> > >
> > > .HLL 'perl5', perl5_group
> > > .namespace ['Foo']
> > >
> > > $P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
> > > $P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
> > >
> > > $P0 = get_global 'x' # ['perl5';'x']
> > > $P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
> > >
> > > $P0 = get_abs_global 'x' # ['x']
> > > $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
> >
> > This is non-evil. :)
>
> <grin/>
>
> > I would rename 'get_cur_global' to 'get_global'. The selected namespace
> > indicates that most of the code belongs in that namespace, so it's
> > likely that most of the variables do too. (There are variations, but
> > that's at least the common case.)
>
> Works for me. And that is the current meaning of two-parameter find_global,
> so it's not a stretch.
Works for me too. I'm not sure that I like the rename (I can't
decide), but the name itself doesn't matter much. The new opcodes (the
presence of get_cur_global) may actually make things easier for Tcl if
we ever compile to 100% inlined PIR.
This is a different route than I was trying to take us, but it should
be almost functionally equivalent, so I'm happy with it.
Patrick R. Michaud
> Relative is the usual apposite to absolute, but we have a three-way
> logic here, so appositives don't really work. I think that "hll" is the
> best I can think of, and given the existing ".HLL" directive, its meaning
> is immediately clear:
>
> .HLL 'perl5', perl5_group
> .namespace ['Foo']
>
> $P0 = get_global 'x' # ['perl5';'Foo';'x']
> $P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
>
> $P0 = get_hll_global 'x' # ['perl5';'x']
> $P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x']
>
> $P0 = get_abs_global 'x' # ['x']
> $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
Pardon me for coming in late to the thread -- this past week I
was on a trip with limited network access and I'm just now catching
up.
What's the status on the above...has it been blessed/implemented yet?
This looks to me like exactly what is needed/desired for the various
HLL's I'm working with.
Thanks,
Pm
Chip Salzenberg
> On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > Relative is the usual apposite to absolute, but we have a three-way
> > logic here, so appositives don't really work. I think that "hll" is the
> > best I can think of, and given the existing ".HLL" directive, its meaning
> > is immediately clear:
> >
> > .HLL 'perl5', perl5_group
> > .namespace ['Foo']
> >
> > $P0 = get_global 'x' # ['perl5';'Foo';'x']
> > $P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
> >
> > $P0 = get_hll_global 'x' # ['perl5';'x']
> > $P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x']
> >
> > $P0 = get_abs_global 'x' # ['x']
> > $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
>
> This looks to me like exactly what is needed/desired for the various
> HLL's I'm working with.
Allison has blessed it except for the detail of the "_hll_" in the HLL
selection. I haven't started implementing it yet, though nothing stands
in my way technically.
I've suggested that get_namespace follow exactly the same pattern, but
so far she hasn't commented on that suggestion at all.
BTW I expect find_global to keep working for a good while. The only thing
that may change incompatibly in _any_ of this is the meaning of:
PMC = get_namespace KEY,STR
which currently starts from the HLL root but which I'm proposing should
start at the current namespace. *If* that additional proposal goes forward,
any place you currently have the above, you would just change it to:
PMC = get_hll_namespace KEY,STR
PS: None of this is in any PDD yet -- not a complaint, just an observation. :-)
--
Chip Salzenberg <ch...@pobox.com>
Patrick R. Michaud
> On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > > Relative is the usual apposite to absolute, but we have a three-way
> > > logic here, so appositives don't really work. I think that "hll" is the
> > > best I can think of, and given the existing ".HLL" directive, its meaning
> > > is immediately clear:
> > > .HLL 'perl5', perl5_group
> > > .namespace ['Foo']
> >
> > What's the status on the above...has it been blessed/implemented yet?
> > This looks to me like exactly what is needed/desired for the various
> > HLL's I'm working with.
>
> Allison has blessed it except for the detail of the "_hll_" in the HLL
> selection. I haven't started implementing it yet, though nothing stands
> in my way technically.
>
> I've suggested that get_namespace follow exactly the same pattern, but
> so far she hasn't commented on that suggestion at all.
I really like both of these suggestions. We also noted on #parrot that
get_hll_global would really simplify things for the Tcl folks, which
currently go through a macro to achieve the same effect.
> BTW I expect find_global to keep working for a good while. The only thing
> that may change incompatibly in _any_ of this is the meaning of:
>
> PMC = get_namespace KEY,STR
>
> which currently starts from the HLL root but which I'm proposing should
> start at the current namespace. *If* that additional proposal goes forward,
> any place you currently have the above, you would just change it to:
>
> PMC = get_hll_namespace KEY,STR
I'm not currently using get_namespace in any form, so I have no problem
with this switch.
FWIW, a quick grep of the parrot tree seems to indicate that the only
places using get_namespace outside of the Parrot sources and tests
are in languages/dotnet (12 occurrences) and languages/tcl (2 occurrences).
Pm
Matt Diephouse
> On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
> > On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> > > On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > > > Relative is the usual apposite to absolute, but we have a three-way
> > > > logic here, so appositives don't really work. I think that "hll" is the
> > > > best I can think of, and given the existing ".HLL" directive, its meaning
> > > > is immediately clear:
> > > > .HLL 'perl5', perl5_group
> > > > .namespace ['Foo']
> > > > $P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
> > > > $P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x']
> > > > $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
> > >
> > > What's the status on the above...has it been blessed/implemented yet?
> > > This looks to me like exactly what is needed/desired for the various
> > > HLL's I'm working with.
> >
> > Allison has blessed it except for the detail of the "_hll_" in the HLL
> > selection. I haven't started implementing it yet, though nothing stands
> > in my way technically.
> >
> > I've suggested that get_namespace follow exactly the same pattern, but
> > so far she hasn't commented on that suggestion at all.
>
> I really like both of these suggestions. We also noted on #parrot that
> get_hll_global would really simplify things for the Tcl folks, which
> currently go through a macro to achieve the same effect.
You mean get_abs_global, actually. The proposed get_hll_global opcode
mirrors the existing find_global exactly. :-)
Allison Randal
>
> Hrm. Relative is the usual apposite to absolute, but we have a three-way
> logic here, so appositives don't really work. I think that "hll" is the
> best I can think of, and given the existing ".HLL" directive, its meaning
> is immediately clear:
I like that.
> Seems to me that we should have get_namespace patterned just alike:
Agreed.
> I'm still not entirely happy with "abs", but I can live with it, especially
> since its use should be quite rare.
Yeah, if we're going for meaning-based naming in the 'hll' version, it'd
be nice to have a meaning-based name for the absolute-root version.
Perhaps get_root_global or get_base_global (I like 'base' better).
I'll work on updating the namespaces PDD tomorrow.
Allison
Chip Salzenberg
Erm, only if it's the explicit-namespace version of find_global.
Summarizing the conversion chart:
$P0 = find_global 'x' -> $P0 = get_global 'x'
$P1 = find_global ['ns'],'x' -> $P0 = get_hll_global ['ns'],'x'
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> Chip Salzenberg wrote:
> > ".HLL" directive, its meaning is immediately clear:
>
> I like that.
Great!
> > Seems to me that we should have get_namespace patterned just alike:
>
> Agreed.
Great^2!
> > I'm still not entirely happy with "abs", but I can live with it, especially
> > since its use should be quite rare.
>
> Yeah, if we're going for meaning-based naming in the 'hll' version, it'd
> be nice to have a meaning-based name for the absolute-root version.
> Perhaps get_root_global or get_base_global (I like 'base' better).
I could live with either get_root_global or get_base_global. I may commit a
patch that contains one or the other but only as a development step, not as
a stealth vote.
(You'll probably want to know that "get_base_global" has a slight object-
orientation connotation from my C++ experience; in C++, a superclass is
called a "base class". Whether this matters depends entirely on whether
slight C++ semantic bleed is likely to interfere with the Parrot user base;
and even I must admit that the answer is probably "no".)
> I'll work on updating the namespaces PDD tomorrow.
Great^3 that this happens automagically (from my POV) while I'm coding. :-D
--
Chip Salzenberg <ch...@pobox.com>
Bob Rogers
Date: Mon, 10 Jul 2006 19:41:38 -0700
(You'll probably want to know that "get_base_global" has a slight object-
orientation connotation from my C++ experience; in C++, a superclass is
called a "base class". Whether this matters depends entirely on whether
slight C++ semantic bleed is likely to interfere with the Parrot user base;
and even I must admit that the answer is probably "no".)
IIRC, "base class" predates C++. So you may have stolen this from C++,
but C++ stole it from somebody else, so no need to feel guilty. ;-}
-- Bob Rogers
http://rgrjr.dyndns.org/
Allison Randal
Aye, "base" is not ideal ("base class" is a generic term, used even in
Perl), it also conflicts with numeric "bases": "counting in base 2",
etc. But "root" also conflicts with "root" user, and mathematic roots
(square root, etc), not to mention the root of a tree in a
transformation (a term that will become more common since the compiler
tools are based on tree transformations). There just aren't many options
to choose from in English.
Maybe get_top_global, since it carries the idea that you need to specify
the namespace path from the top. It's also 3 letters, to match 'hll',
for whatever small value that adds. We can claim it stands for "the 'ole
(bl***y) path". ;)
Allison
Chip Salzenberg
> Maybe get_top_global .... We can claim it stands for "the 'ole (bl***y)
> path". ;)
Now that's the Perl design metric I've come to know and love. :-)
Seriously, it works for me.
I suggest that you delay the final choice utnil you write the PDD, then
to with whatever opcode name looks best in the =item that precedes its
description. :-)
--
Chip Salzenberg <ch...@pobox.com>