Arrays, lists, referencing (was Re: Arrays vs. Lists)
> But is it OK for a list to be silently promoted to an array when used
> as an array? So that all of the following would work, and not just 50%
> of them?
> (1..10).map {...}
> [1..10].map {...}
And somehow related to all this . . .
Let's assume for the moment that there's still a functional version of
the C operator (I think Larry indicated that it probably wouldn't
be going away, despite <~ and friends). I'm also going to use $_ in the
code block, even though things like $^a exist. Lowest common
denominator and all that.
Let's also assume:
@count = (1, 2, 3, 4, 5);
@smallcount = (2, 3, 4);
$#array works like in Perl5 (if not, you can mentally change my
notation below)
What's the result of these statements in Perl6?
@a = map { $_ + 1 } @count; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } @count[0..$#count]; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } (1, 2, 3, 4, 5); # my guess: @a = (2, 3, 4, 5, 6)
All fair enough. Now how about these?
@a = map { $_ + 1 } (1, @smallcount, 5); # Three or five elements?
@a = map { $_ + 1 } (1, @smallcount[0..$#smallcount], 5); # Array slices appear to
be lists
@a = map { $_ + 1 } \@count; # Map the array or its reference?
@a = map { $_ + 1 } [1, 2, 3, 4, 5]; # one-element list or five-element array?
$ref = @count;
@a = map { $_ + 1 } $ref; # Map the scalar or the array it refers to?
@a = map { $_ + 1 } @count;# Am I sure about this one any more, given the one
above?
There's a slippery slope here that needs propping up.
It's things like this that make me worry a great deal about implicit
dereferencing, something which is going to be happening a lot more in
Perl6 than in Perl5.
Where's the list of rules that state:
- when implicit referencing happens
- when implicit dereferencing happens
- when arrays are flattened into lists, and
- how to stop this from being the default, and
- how to make it happen when it isn't the default
- how arrays of pairs, lists of pairs (i.e., "hash literals")
and hashes are related, and when one can be substituted for
another (and when one is implicitly converted to another)
?
I think some of this is in A2, but not all of it.
I'm prepared to summarize the outcome of this discussion if we actually
arrive at anything definite.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"Oh, she's got it bad." "What? What has she got?" "Isn't it obvious, Daddy?
Ariel's in *love*." - _The Little Mermaid_
Re: Arrays, lists, referencing (was Re: Arrays vs. Lists)
On Tuesday, February 11, 2003, at 04:56 PM, Deborah Ariel Pickett
wrote:
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just
50%
of them?
(1..10).map {...}
[1..10].map {...}
And somehow related to all this . . .
I think some of this is in A2, but not all of it.
Here are some of the answers from my own notes. These behaviors have
all been confirmed on-list by the design team:
An @array in list context returns a list of its elements
An @array in scalar context returns a reference to itself (NOTE1)
An @array in numeric (scalar) context returns the number of elements
An @array in string (scalar) context returns a join of its elements
An $arrayref in list context returns an arrayref (NOTE2)
An $arrayref in scalar context returns an arrayref
An $arrayref in numeric (scalar) context returns ??? (NOTE3)
An $arrayref in string (scalar) context returns ???
Note that that's pretty consistent with how it works now.
(NOTE1): This is the big change. It's what allows us to treat arrays
as objects, and call methods on them like @array.length. I don't think
anyone will argue that's not a good thing.
(NOTE2): Note that this is a non-change. If we changed it so that an
arrayref flattened itself in array context, you could never have
complex data structures, because [[1,2],[3,4]] would always be the same
as [1,2,3,4].
(NOTE3): I have not been able to find explicitly confirmed behaviors
for these two. It has been implied that they return $arrayref.length
and $arrayref.string (or whatever those methods are called). Maybe.
--- List Flattening ---
The confusing behavior is, of course, that the list
(@a,@b,@c)
is seen as being treated differently in different syntactic contexts.
In the case of:
sub foo(@p1,@p2,@p3);
&foo(@a,@b,@c);
the arrays @a, @b, and @c are NOT flattened, but are passed as @p1,
@p2, and @p3. Likewise, in:
my(@d,@e,@f) := (@a,@b,@c);
the same is true. But in ALL other circumstances, like
my(@d,@e,@f) = (@a,@b,@c);
an array in list context simply returns it's elements, such that @d =
(@a,@b,@c), @e=(), @f=(). So what's the deal?
My own two-sentence explanation for why this is is that in the first
two examples, C and C<:=>, you're binding one variable to another,
NOT dealing with the array-ness of those variables at all. E.G.
@a := @b
makes @a refer to the same array object as @b refers to, whereas
@a = @b
simply says to copy all elements _contained within_ @b into @a. So
it's not that arrays are behaving differently in different situations,
because they're NOT... the same rules always apply. It's just that
C and C<:=> are specific, binding-style operations... they do the
same thing for scalar variables, too.
There, how convincing did that sound?
MikeL
Re: Arrays, lists, referencing (was Re: Arrays vs. Lists)
> Here are some of the answers from my own notes. These behaviors have > all been confirmed on-list by the design team: > > An @array in list context returns a list of its elements > An @array in scalar context returns a reference to itself (NOTE1) > An @array in numeric (scalar) context returns the number of elements > An @array in string (scalar) context returns a join of its elements > > An $arrayref in list context returns an arrayref (NOTE2) > An $arrayref in scalar context returns an arrayref > An $arrayref in numeric (scalar) context returns ??? (NOTE3) > An $arrayref in string (scalar) context returns ??? > > Note that that's pretty consistent with how it works now. > > (NOTE1): This is the big change. It's what allows us to treat arrays > as objects, and call methods on them like @array.length. I don't think > anyone will argue that's not a good thing. > > (NOTE2): Note that this is a non-change. If we changed it so that an > arrayref flattened itself in array context, you could never have > complex data structures, because [[1,2],[3,4]] would always be the same > as [1,2,3,4]. > > (NOTE3): I have not been able to find explicitly confirmed behaviors > for these two. It has been implied that they return $arrayref.length > and $arrayref.string (or whatever those methods are called). Maybe. All right, I'm prepared to buy that. Now how would it extend to hashes? A %hash in list context returns a list of its pairs (NOTE4) A %hash in scalar context returns a reference to itself (NOTE1) A %hash in numeric (scalar) context returns (?) A %hash in string (scalar) context returns (?) A $hashref in list context returns a hashref (NOTE2) A $hashref in scalar context returns a hashref A $hashref in numeric (scalar) context returns (?) A $hashref in string (scalar) context returns (?) (NOTE4): Or is it a flattened list of key-values? And how would it extend to the finer-grained contexts we're getting in Perl6 (integer numeric scalar context, hashref context, ...)? Our complete list of contexts now is quite a hierarchy. > --- List Flattening --- > My own two-sentence explanation for why this is is that in the first > two examples, C and C<:=>, you're binding one variable to another, > NOT dealing with the array-ness of those variables at all. E.G. [...] > There, how convincing did that sound? Pretty convincing. In fact, it sounds like this "binding" mode is nothing more than another facet of context (i.e., difference in meaning imposed by surrounding code). Sort of like this: An @array in nonbinding list context returns a list of its elements. An @array in binding list context returns the symbol table reference for itself An @array in nonbinding scalar context returns a reference to itself. An @array in binding scalar context returns the symbol table reference for itself Would that fly? If so, I'd expect the new generic want() operator to be able to detect it. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] "Games people play, you take it or you leave it, things that they say just don't make it right. If I'm telling you the truth right now, do you believe it? Games people play in the middle of the night." - _Games People Play_, APP
