> 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<sub> 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
