Keys

1 view
Skip to first unread message

Dan Sugalski

unread,
May 31, 2005, 4:42:10 PM5/31/05
to perl6-i...@perl.org
Since this is coming back up, and a ref's in order...

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

unread,
May 31, 2005, 10:10:42 PM5/31/05
to perl6-i...@perl.org
> 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?

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

unread,
Jun 1, 2005, 3:29:40 AM6/1/05
to TOGoS, perl6-i...@perl.org
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"

leo

TOGoS

unread,
Jun 1, 2005, 4:07:49 AM6/1/05
to perl6-i...@perl.org
perl6-internals: the place to go to have people tell
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

unread,
Jun 1, 2005, 5:40:25 AM6/1/05
to perl6-i...@perl.org
--- Leopold Toetsch <l...@toetsch.at> wrote:
> TOGoS <chumps...@yahoo.com> wrote:
>
> > --- 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

unread,
Jun 1, 2005, 5:05:07 AM6/1/05
to TOGoS, perl6-i...@perl.org
TOGoS <chumps...@yahoo.com> wrote:

[ 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

unread,
Jun 1, 2005, 8:53:00 AM6/1/05
to TOGoS, perl6-i...@perl.org
At 7:10 PM -0700 5/31/05, TOGoS wrote:
> > 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

unread,
Jun 1, 2005, 9:26:45 AM6/1/05
to TOGoS, perl6-i...@perl.org
On Tue, May 31, 2005 at 07:10:42PM -0700, TOGoS wrote:
> 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>

Reply all
Reply to author
Forward
0 new messages