Namespaces, part 2
Dan Sugalski
back up again.
As we last left it, I'd proposed we access namespaces via a
multidimensional key to dodge the whole "What separator does *this*
language use?" problem. I'd also proposed that we split the namespace
and thing name into separate parameters.
Turning the namespace selector into a multidimensional key just seems
to make sense. I'd originally hoped we could keep things
unidimensional, in one really big hash, but that idea now seems
charmingly naive, and if we're going to be multidimensional we might
as well do it right. I don't see any reason to not just do this.
The reason for splitting the lookup into two parameters, namespace
and name, instead of one combined parameter, is a bit less solid, so
I'm up for arguments here. Consider, however, the case where we're
accessing multiple named globals, a not uncommon thing. If we go with
the single parameter case it looks like:
load_global $P1, ['foo'; 'bar'; '$baz']
load_global $P2, ['foo'; 'bar'; '$xyzzy']
but if we go with the split parameter case it looks like:
load_global $P1, ['foo'; 'bar'] '$baz'
load_global $P2, ['foo'; 'bar'] '$xyzzy'
The difference there being that, rather than having two separate
constant keys we have one constant key and two string constants. This
should result in less memory usage and a faster startup time for
bytecode that accesses globals (which should pretty much be all of
it).
It has the additional advantage of *not* needing to construct an
extra key when doing symbolic access to symbol tables. Code like:
$$foo = 12;
where $foo has a string in it won't need to have a key constructed --
the bytecode would look like:
load_global $P1, CURRENT_PACAKGE_CONSTANT, $foo
$P1 = 12
assuming the string in $foo has no package qualifications. If it does
a key needs to be created, of course, but it makes one of the access
legs (the leg with no qualification) faster without impacting the
speed of the less-common package-qualified leg.
Time for discussion, and this time I promise to keep up. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Chris Shawmail
> Sent: Tuesday, December 16, 2003 6:56 AM
> To: perl6-i...@perl.org
> Subject: Namespaces, part 2
>
> load_global $P1, ['foo'; 'bar'] '$baz'
> load_global $P2, ['foo'; 'bar'] '$xyzzy'
I'm not at all familiar with the intricacies of Parrot internals anymore,
things having gone flying over my head long ago, but may I humbly suggest
that there might be some merit to creating some kind of shortcut to a
namespace stored in a Px register?
load_namespace $P1, ['foo'; 'bar']
load_global $P2, $P1, '$baz'
Might be a good place to specialize the code for language constructs like
Python's
from module import *
Or something Perl6-ish involving "given". Subsequent "load_global" usage
wouldn't have to do the work of actually finding that 'foo::bar' namespace
each time.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.545 / Virus Database: 339 - Release Date: 11/27/2003
Leopold Toetsch
> load_global $P1, ['foo'; 'bar'] '$baz'
> load_global $P2, ['foo'; 'bar'] '$xyzzy'
> The difference there being that, rather than having two separate
> constant keys we have one constant key and two string constants. This
> should result in less memory usage and a faster startup time for
> bytecode that accesses globals (which should pretty much be all of
> it).
I already commented on the last one: Above syntax is hmmm - strange
(bracketed access on nothing doesn't really fit). So why not use a
scheme, that matches current syntax:
getinterp $P1 # (or) get_namespace PMC
set $P2, $P1['foo'; 'bar'; '$baz'] # get var
and (optimized for multiple access)
set $P3, $P1['foo'; 'bar'] # get foo::bar namespace
set $P2, $P3['$baz'] # get var
This needs a bit of work (CSE) and eventually one more register, but
makes it usable for all multi-keyed opcodes - no special syntax is
needed, just a namespace PMC.
Anyway - my original question was on attributes: how are these accessed?
leo