Dave Mitchell wrote:
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
IMHO some sort of proxy could be passed here, saying: "if you write to me, this will be at @a[0]". Or auto-vivify the entry.
This is what Perl 5 does at the moment:$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
Ah, same idea ;-)
It's probably not too complex, it's IMHO the same, what we would need to implement the multi_keyed opcodes like:However, I think this is clumsy and overly complex; since Perl6 allows us to declare parameters rw or whatever, I think it should always autovivify unless we know the param is read-only (or in-only, or whatever the correct terminology is).
@a[$x] = @b{$y} - @c[2;$i]
We can't implement all the opcodes per se, this would need ~64K ops, so one of my proposals (some time ago) was, to split this operation in 3 keyed fetch ops and one plain subtraction. The LHS whould need - as I can set it now - a very similar treatment like above's example.
To come back to the array example:
- when the sub param is ro, you said it, no autovifiy should happen
- for rw (the default?) there is always a chance, that no write will occur, and for the case nothing gets written, we have a volatile PMC (the proxy) collected with the next DOD run. With autovivification we create an anchored value, that is more expensive.
A (of course) constructed example could check in a subroutine, if one/some/all elements exist
sub e() {return exists shift;}
for ([EMAIL PROTECTED]) -> $i { do_some($i) if e($a[$i]); }
# modulo syntax, operator and other errs :)
And, from DWIM POV, autovivification was not the clearest things in the docs, when it could happen or not. I would just expect: when I don't set this very elememt in this array, why is something there.
leo
