PerlHash using PMCs for keys?
Togos
PMCs as keys? I mean so that:
$P0 = $P1[$P2]
where $P1 is a PerlHash, would work. The way it works
now is that it complains that you can't use a PMC as a
key. So my compiler has to spit out about 20 lines of
code for every sub-element access that tries to guess,
depending on the type of the key and the type of the
aggregate, whether to take the string value or the
integer value of the key before using it. Which is
totally ugly.
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer
Stéphane Payrard
> Should aggregate PMCs (like PerlHash) be able to take
> PMCs as keys? I mean so that:
>
> $P0 = $P1[$P2]
>
> where $P1 is a PerlHash, would work. The way it works
> now is that it complains that you can't use a PMC as a
> key. So my compiler has to spit out about 20 lines of
> code for every sub-element access that tries to guess,
> depending on the type of the key and the type of the
> aggregate, whether to take the string value or the
> integer value of the key before using it. Which is
> totally ugly.
I have proposed a patch that was dismissed by Leo on the ground
that it would affect performance. I thought that the general case
was non composite keys and that parrot should be optimized for
that. So avoiding generating more IMC code to create keys seemed
good to me. But no one came forward to defend my idea so I thought
it was bad and did not advocate it further. I don't know if it
still works though.
--
stef
Leopold Toetsch
> Should aggregate PMCs (like PerlHash) be able to take
> PMCs as keys? I mean so that:
> $P0 = $P1[$P2]
Just use a Key PMC for $P2.
$P2 = new Key
$P2 = "key_string"
...
leo
Piers Cawley
So, just for fun I added the following test to t/pmc/perlhash.t:
new P10, .PerlHash
new P1, .PerlString
set P1, "Bar"
new P2, .Key
set P2, P1
set P10[P2], "Food\n"
set S0, P10[P2]
print S0
new P3, .Key
set P2, P1
set S1, P10[P2]
print S1
end
Just to test that two Keys created from the same PMC would fetch the
same thing from the hash.
Imagine my surprise when the test blew up with 'Key not a string!'
before producing any output.
Perl 6 supports using full on objects as keys in its hashes. It seems
that having parrot do the same would be a Good Thing.
Leopold Toetsch
> Leopold Toetsch <l...@toetsch.at> writes:
>> Just use a Key PMC for $P2.
> So, just for fun I added the following test to t/pmc/perlhash.t:
> new P10, .PerlHash
> new P1, .PerlString
> set P1, "Bar"
> new P2, .Key
> set P2, P1
^^^
C<set Px, Py> aliases the two PMCs, both are pointing to the same PMC
then. You'd like to use C<assign> here.
> new P3, .Key
> set P2, P1
^^
typo?
> Perl 6 supports using full on objects as keys in its hashes. It seems
> that having parrot do the same would be a Good Thing.
The main problem here is, what does ...
set P0, P1[P2]
... mean: keyed_string or keyed_integer, i.e. hash or array lookup.
The Key PMC provides this information, a plain string could be used in
both ways:
set P2, "42"
set P0, P1[P2]
It depends of course on the aggregate, what kind of key it would like to
use, but e.g. for an OrderedHash PMC, which supports lookup by string
*and* by integer, the usage is ambiguous.
We could change C<key.c:key_integer()> to extract a number with
C<get_integer> from any PMC and do the same with C<key_string> but some
keyed usage needs a defined type.
leo
Togos
> new P10, .PerlHash
> new P1, .PerlString
> set P1, "Bar"
> new P2, .Key
> set P2, P1
Oops! should be assign!
This is one of the reasons I think code like
$P0 = new PerlString
$P0 = "foo"
should be illegal. If people were forced to 'assign'
where assigning is what is intended, this kind of
error wouldn't come up as often. Saying set when you
mean assign is just sloppy. People really ought to
understand the difference *before* they start coding.
<rant about 'add' semantics goes here>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Piers Cawley
> Piers Cawley <pdca...@bofh.org.uk> wrote:
>> Leopold Toetsch <l...@toetsch.at> writes:
>
>>> Just use a Key PMC for $P2.
>
>> So, just for fun I added the following test to t/pmc/perlhash.t:
>
>> new P10, .PerlHash
>> new P1, .PerlString
>> set P1, "Bar"
>> new P2, .Key
>> set P2, P1
> ^^^
>
> C<set Px, Py> aliases the two PMCs, both are pointing to the same PMC
> then. You'd like to use C<assign> here.
Of course I would. Oops.
>
>> new P3, .Key
>> set P2, P1
> ^^
> typo?
Yes, and should be an assign.
>> Perl 6 supports using full on objects as keys in its hashes. It seems
>> that having parrot do the same would be a Good Thing.
>
> The main problem here is, what does ...
>
> set P0, P1[P2]
>
> ... mean: keyed_string or keyed_integer, i.e. hash or array lookup.
> The Key PMC provides this information, a plain string could be used in
> both ways:
>
> set P2, "42"
> set P0, P1[P2]
>
> It depends of course on the aggregate, what kind of key it would like to
> use, but e.g. for an OrderedHash PMC, which supports lookup by string
> *and* by integer, the usage is ambiguous.
I'm not advocating removing the key object for disambiguating this sort
of thing.
> We could change C<key.c:key_integer()> to extract a number with
> C<get_integer> from any PMC and do the same with C<key_string> but some
> keyed usage needs a defined type.
I'd argue that at the base level all objects should have a 'hash_int'
method (or some other name to be decided) which generates a hash
integer appropriate to the object. See countless smalltalk images for
such usage.