> > > Actually, you can't reference a slice!  Where the heck does the
> > > reference point?  I would probably do:

> > Of course not. I presume it points to something non-existent just like
> > a substring reference would in perl5 :-)

> > $ perl -le '$a = "pie contest"; $b = \substr $a, 1, 9; $$b = "arro"; print $a'
> > parrot

> I don't think you're supposed to do that:

>     % perl -le '$a = "foobar';  $b = \substr $a,2,3; $a .= "jibby"; $$b = "OBA"; print $a'
>     foobarjibby

> Because it copies the buffer to resize, and $b points back into the old buffer...

> The tricky stuff comes in in cases like:

>     my @a = (1,2,3,4,5);
>     my $sref = \@a[1..3];
>     shift @a;
>     @$sref = (4,3,2);
>     @a  # ?  (4,3,2,5) or (2,4,3,2) ?

> Those are just semantics to be nailed down, but it's tricky
> nonetheless... oh and let's not forget multidimensional slices.

> This really comes down to an issue that I've been biting my
> fingernails about for some time: iterators.  There are two mutually
> exclusive kinds of iterator semantics:  list and array.  In the above
> example, (4,3,2,5) would be list semantics; (2,4,3,2) would be array.
> And both of them are correct (or wrong) in certain applications.

> For implementation reasons, I'm not sure it's possible to have both
> kinds of iterator pointing into the same kind of array.  Perhaps we
> need a List class for an array which doesn't support indexing... but
> then it doesn't really deserve the @ medal does it?

> Hmm...

> Luke

> > Nicholas Clark