Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
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'] 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
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
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 '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'] 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. 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 [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
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. 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
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Patrick R. Michaud [EMAIL PROTECTED] wrote: 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. :-) -- matt diephouse http://matt.diephouse.com
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Chip Salzenberg wrote: 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
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Mon, Jul 10, 2006 at 06:57:06PM -0700, Matt Diephouse wrote: Patrick R. Michaud [EMAIL PROTECTED] wrote: 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. :-) 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 [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Mon, Jul 10, 2006 at 07:22:21PM -0700, Allison Randal wrote: Chip Salzenberg wrote: 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. 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 [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Thu, Jul 06, 2006 at 05:39:45PM -0700, jerry gay wrote: 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 [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
{ 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) }
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 [EMAIL PROTECTED]
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Chip Salzenberg [EMAIL PROTECTED] wrote:
{ 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.
--
matt diephouse
http://matt.diephouse.com
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
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. :) * 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 Cinterpinfo .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
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Matt Diephouse wrote: 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
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
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.) 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
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
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. 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 [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Allison Randal wrote:
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-rans, 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
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Chip Salzenberg wrote: 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
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Thu, Jul 06, 2006 at 12:11:47PM -0700, Allison Randal wrote: 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 [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
{ All you HLL implementors and other PIR users out there, please be assured
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 Cinterpinfo .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 [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On 7/6/06, Chip Salzenberg [EMAIL PROTECTED] wrote: 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'] 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' ] i don't see any examples that make it easy to look in that direction. ~jerry
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
Allison Randal [EMAIL PROTECTED] wrote: 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. -- matt diephouse http://matt.diephouse.com
