|Don't ask to ask, just ask|
Re: Some Insights from a Traveler Between Languagesby TimToady (Parson)
|on Apr 23, 2005 at 19:28 UTC||Need Help??|
In the first case, you get a tuple assigned to foo, and in the second case a list assigned to bar. There's nothing confusing about this.
Except you've just forced the new user to learn the difference between mutable and immutable. Perl largely succeeds in hiding this difference from new users.
In the third case, you end up with a variable that holds the length of the array on the RHS.
Only by accident, in this case. Perl 5 is returning the final value of the list, on the assumption that the user meant to use a C-style comma operator, which is a bad assumption in this case. Perl 6 does not have the C-style comma operator, so you automatically get a reference to the list into $baz. If you use that reference in numeric context, you'll get the length, but if you use it as if it were a tuple, it'll behave as a tuple, and if you use it as a boolean, it'll still behave reasonably.
@biz will still end up with a single element, since it is still assumed that if you use [...] in list context, you really mean it. But if you want more Pythonly semantics for all of those, just use the new := binding operator instead of =, since Python really only has binding, not assignment.
Perl's built-in "length" function is downright silly.
Indeed, I agree, but for different reasons. Perl 6 will not have a length function at all, because "length" is too general a concept in the age of Unicode. You have to be more specific, and specify the units. So we have the following methods:
Note that this also lets you ask for things like
But having said all that, I also agree with your reason, which is why Perl 6 no longer forces evaluation of scalars in scalar context, but autoenreferences anything it can autoenreference. The underlying problem with Perl 5's length(@array) is that it's forcing evaluation of @array in generic scalar context without knowing whether the array is eventually going to be used in a boolean, string, array, or reference context. Perl 6 straightens out this mess without breaking the behavior that Perl 5 programmers actually want. They don't want an array to return its length in scalar context. They want the array to return its length in numeric context. And they don't actually want its length in boolean context--they merely want to know if the array thinks of itself as "true". In Perl 6, scalar context means "I don't know how this object is going to be used yet, so let's not commit yet."
Perl is easily my favorite language. However, it would clearly seem to have dropped the ball in these regards.
I hope you will discover that Perl 6 has again picked up most of the balls it dropped in the past, hopefully without dropping too many new balls. It would be possible (though unpopular) to go back through all the recent nodes on PM that complain about any trap in Perl 5, and add annotations about whether Perl 6 addresses the problem. My rough estimate is that at least 90% of those annotations would say "Fixed in Perl 6". I have to sit on myself not to follow up every time I see one of those nodes. It's hard, because I like to brag. That's the problem with Hubris... :-)