So, I was thinking about how symbol tables are going to work, and I
remembered that Dan had said that he wanted hashes to preserve their
insertion order on print out.
Which led me to think that it'd be really nice if there was some way
of addressing hashes with integers to get the 'nth thing'
inserted. This could lead to some useful compiler optimization
possibilities. Consider:
my $foo = 10;
sub thing($arg) {
return { $arg + $foo++ }
}
Which is ugly and does nothing, but will serve for now. Now, if this
is run by an interpreter, you'd probably see the internal 'return {
$arg + $foo++ }' becoming (this is pseudo code, not parrot code).
$register{SCRATCH1} = $register{ENVT}->lookup('$arg');
$register{SCRATCH2} = $register{ENVT}->lookup('$foo');
$register{SCRATCH1} = $register{SCRATCH1} + $register{SCRATCH2};
$register{SCRATCH2} = $register{SCRATCH2} + 1;
$register{ENVT}->bind('$foo' => $register{SCRATCH2});
But, if we assume that the first thing that gets inserted into an
environment hash is its parent environment, then a compiler could turn
this into:
$register{SCRATCH1} = $register{ENVT}[1] + $register{ENVT}[0][1];
$register{ENVT}[0][1] = $register{ENVT}[0][1] + 1;
Which takes advantage of the compilers knowledge of the current
compilation state to avoid the runtime cost of the environment
search.
The question then becomes how does one distinguish within parrot
between %HASH{1} and %HASH[1]. I confess that I wouldn't be
desperately keen on having to do that using an approach along the
lines of '%HASH.as_array.[1]', unless the array returned by .as_array
could be used lvaluably to change the values held in the hash...
Thoughts?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
