Keys
Dan Sugalski
The way keyed access is supposed to work is this.
A key structure is an array of three things:
1) A key
2) A key type
3) A 'used as' type
The key can be an integer, string, or PMC, and is, well, the key. The
thing we use to go looking up in an aggregate.
The key type notes the type of a key -- whether it's an integer, a
string, or a PMC. Nothing at *all* fancy, basically a "what thing is
in the key union slot".
The 'used as' type indicates whether this key is to be used to do a
by-integer-index (array) access or by-string-index (hash) access.
So, code like:
$a{'foo'}
would generate a key struct that looks like:
'foo'
string
as-hash
while $a['foo'] generates:
'foo'
string
as-integer
and $a{$b} generates
$b
PMC
as-hash
and $a{3} generates
3
integer
as-hash
*If* a PMC supports it, it may complain if the basic type is
incorrect (that is, you pass in a string for array access) but
generally that's a bad thing -- the PMC should just convert. (All the
languages we care about do this, as far as I know)
Keys are multidimensional -- that is, we support real
multidimensional arrays, hashes, arrays of hashes, hashes of arrays,
and so on. That means BASIC code like:
A[1,2,3]
generates a key that looks like:
1
integer
as-integer
2
integer
as-integer
3
integer
as-integer
and perl code like:
$a{'a'}[2]{$b}
*should* get you a structure like:
'a'
string
as-hash
2
integer
as-integer
$b
pmc
as-hash
It is *perfectly* valid to pass in a multidimensional key to a
one-dimensional aggregate, or an n+m dimensional key to an
n-dimensional aggregatge. In that case the aggregate *must* consume
as much of the key as it can, use that to fetch out a PMC, and then
make a keyed access call to the resulting PMC with the remainder of
the key structure. (Those of you old-timers who remember, this is why
the key stuff was done as a singly-linked list once upon a time)
This scheme is fairly straightforward and has the advantage of
allowing true multidimensional data structures (which we really want
for space efficiency) and still handling the more legacy
one-dimensional aggregates of references scheme that, say, perl 5
uses.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
TOGoS
> is to be used to do a by-integer-index (array)
> access or by-string-index (hash) access.
Why not extend this to properties, too?
foo['hello'] becomes
'hello'
string
as-offset
foo{'hello'} becomes
'hello'
string
as-hash
foo.hello becomes
'hello'
string
as-property
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
Leopold Toetsch
> Why not extend this to properties, too?
> foo.hello becomes
>
> 'hello'
> string
> as-property
Because that's an attribute access:
$P0 = getattribute foo, "hello"
leo
TOGoS
you things you already know and not actually answer
your question at all.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
TOGoS
>
> > --- Leopold Toetsch <l...@toetsch.at> wrote:
> >> TOGoS wrote:
> >>
> >> > Why not extend this to properties, too?
> >>
> >> > foo.hello becomes
> >> >
> >> > 'hello'
> >> > string
> >> > as-property
> >>
> >> Because that's an attribute access:
> >>
> >> $P0 = getattribute foo, "hello"
>
> > perl6-internals: the place to go to have people
> tell
> > you things you already know and not actually
> answer
> > your question at all.
>
>
> Anyway - and to run the risk of stating again
> something you already know -
> here is a more verbose explanation:
>
> Perl has keyed access on hashes and arrays:
>
> $v = @a[$k] and $v = %a{$k}
>
> Both would translate to Parrot's:
>
> v = a[k]
>
> and the meaning "indexed" vs "hashed" access would
> be lost. To get that
> information into the opcode, Dan proposed to
> construct keys with an
> "as-xxx" bit to discern these two cases.
>
> You asked to extend that to properties (which are
> actually attributes).
> Well there is no ambiguity in accessing attributes.
> The attribute name
> is a string. There is no need to complicate things
> and replace an access
> with (mostly) constant strings by an extra key PMC
> which has to be
> constructed first.
>
> leo
Ah. Because you'd need to create a key PMC. (I didn't
mean to sound especially annoyed - it's just that
people talking past one another seems to happen a lot
around here)
My view that as long as this construct to indicate
'as' is being considered, that it might as well be
generalized to mean more than just array or hashtable
access. You could let language designers use it for
any sub-element access they come up with. (though I
don't know how this would play with vtables or whether
the mmd stuff covers that)
accessing::a::constant
accessing.an.attribute.1.with.an.int.as.its.name
accessing['something']['by-index'][42]
accessing{'something'}{'by-name'}
accessing->something->by->some->yet->to->be->invented->way
and'yes'i'know'this'isn't'valid'perl'6
it:is:hypothetical:language
Of course, PMCs could feel free to treat them all the
same way. I'm not proposing that this should replace
getattribute (maybe complement it), but for
array/hash/constant/other type things it could be very
useful for languages that like to distinguish between
many ways of accessing sub-objects.
Leopold Toetsch
[ anwser rearranged for readability ]
> --- Leopold Toetsch <l...@toetsch.at> wrote:
>> TOGoS wrote:
>>
>> > Why not extend this to properties, too?
>>
>> > foo.hello becomes
>> >
>> > 'hello'
>> > string
>> > as-property
>>
>> Because that's an attribute access:
>>
>> $P0 = getattribute foo, "hello"
> perl6-internals: the place to go to have people tell
> you things you already know and not actually answer
> your question at all.
???
Dan Sugalski
> > The 'used as' type indicates whether this key
>> is to be used to do a by-integer-index (array)
>> access or by-string-index (hash) access.
>
>Why not extend this to properties, too?
Because properties (and attributes) are metadata. At the moment
properties aren't ordered, but they could be I suppose. (well...
maybe) Attributes certainly are. You may want to access them by name
or by offset, in which case you wouldn't want an as-property flag in
the key, but rather use a key structure to access properties and
attributes.
Chip Salzenberg
> Why not extend this to properties, too?
I don't know of a good use case for that.
Now multidimensional arrays are common enough, and workarounds to
emulate them are enough of a pain[*], that Parrot support for them
makes sense. In contrast, abstracting all structural navigation into
one infrastructure seems more like coolness than usefulness.
[*] Emulated or specialized multidim arrays in Perl 5 (or C++ for that
matter) end up needing proxy objects to represent intermediate
lookup results; e.g. given $tiedarray[0][1], you need a proxy
object to hold on to [ \@specialarray, 0 ] until the [1] comes in.
Having all the keys collected together before the first lookup
avoids that hackery.
--
Chip Salzenberg <ch...@pobox.com>