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?