in reply to On Scalar Context
How do we move to get this standardized and rational? Any hope for Perl6 ( aka 2010? :) )
|Replies are listed 'Best First'.|
Re: Re: On Scalar Context
by demerphq (Chancellor) on Apr 23, 2004 at 15:49 UTC
How do we move to get this standardized and rational?
This is standardized and rational. Its just not applying the (incorrect) naive assumption that calling a subroutine in a given context is like working with an array, hash, or list. Its standardized and rational in that most people would consider the behaviour of most of these items to be perfectly natural and DWIM.
Think about it: What use would each() be if it returned 2 (as an array would) or the value (as a list would). Neither of these is particularly DWIM, and would mean that the language was poorly huffman coded in the sense that youd have to write my ($key)=each %hash; instead of my $key=each %hash; and in my experience wanting the keys of a hash is more common than wanting the values.
Work through perl and youll find that all sorts of stuff has been specifically selected to be DWIM and also more or less huffman coded, the more common keywords are short, the less common ones are longer than their more commonly used relatives (my -> our, push/pop -> splice come to mind, im sure there more). On a few occassions Larry has mentioned in his writing being motivated by brevity, at least in part, in his design methodology.
Meanwhile, never make any assumptions about a list function in scalar context -- it's all random :)
Not random, DWIM (hopefully). But yes, never make any assumptions about the relationship between what a function returns in list or scalar context, or for that matter what it will do in void context. Theres no logic to it, beyond what the author thought was the smartest thing at the time. The point is always check the docs, or the source to see what actually does happen.
If you read p5p you'll find numerous large threads debating how subs can have new behaviour provided for contexts where it isnt already well defined. Somebody recently said something like "the problem with defining the new behaviour is that often the ideas proposed are so far from what the people who actually might do the work to implement the feature would expect that they arent interested in doing so." Which is an interesting point in itself.
First they ignore you, then they laugh at you, then they fight you, then you win.
Most languages don't have return-type overloading with the same arguments, and I consider this a good thing.
I love Perl, but I don't believe in covering for it's faults -- or saying that the faults are really DWIMerry or features.
Well they are features whether you like it or not. Perl was very deliberately designing to work in the way it does. You can certainly disagree about it being a good idea - but it's no accident.
I'm still not seeing what you see is so bad about this behaviour. What would you prefer? Should we have separate reverse_string and a reverse_list functions? Should I have to do my $username = ( getpwuid( $uid ) ) instead of $username = getpwuid( $uid )?
There are certainly alternative solutions to the problem that scalar/list context solves in Perl, but to me they don't seem innately superior to the option that Larry chose.
Personally I've not encountered problems with the scalar return values of functions, and appreciate the concise comprehensible code it allows me to write.
This is a problem with the Perl mindset. DWIM has no value when "Do What I Mean" means different things to different people.
Well now, this is quite a provocative thing to say to an audience of perl fans, so kudos for the big cajones at least.
I think I hear what you are saying about the benefits of consistent behaviour, and I have sympathy for this view. It's just that I think consistency can be taken too far, and the price paid for such consistency is in sophistication, and thereby expressiveness.
If you accept that perl is a language, the primary goal of which is communication, perhaps you can also accept that the process of learning perl is analogous to the process of learning a spoken language.
The spoken language initiate, will obviously have an easier time if the language has only a small number of words, together with a strict and comprehensive set of rules for their usage. If language rules have a wide application, so much the easier.
But the fluent language speaker has a completely different perspective. Imagine how frustrating it would be to not have contractions such as "aren't", and "I'm". Imagine having only negating modifiers such as with "good" and "ungood" instead of antonyms like "good" and "bad".
Now, you might think I'm stretching the analogy too far (it's true I'm often guilty of this), but reflect on how you use your preferred programming language, let's say perl for the sake of argument. Think of how often you use $_.
Think also about code that you would generally upvote; is it spelled out in baby talk, or is it laden with expressive idioms?. If we elevate the importance of consistency as you would define it, we would necessarily lose one of the defining characteristics of perl.
To borrow from a respected perlmonk's home node, perl is complicated in a good way, and none of us would exchange that, not for all the consistency in China.
DWIM refers to doing something useful rather than providing something useless (e.g. because of lack of forethought or because of a blind drive for consistency). This is not a problem, and it does have value.
«"Do What I Mean" means different things to different people» is a straw man. It's still better to provide something that's generally useful over something that isn't.
Re: Re: On Scalar Context
by ambrus (Abbot) on May 13, 2004 at 18:39 UTC
Most of the functions we're speaking in this node (sort, keys, map, stat) just don't have mush sense in scalar sense. I mean, perl is designed (?) so that you can not get caught by calling a function in scalar context when you'd mean a list context.
Suppose for example that you want to use stat. You know what it does, so you expect an array from it. As you want to use some specific entries of the array, you won't write code like $permissions= stat $filename; that just means nothing. If you use something as a list, you automatically call it in array context.
Compare this with the other way. Calling a function that you expect to return one single value IS a possible trap, for example, you might accidentally write
and expect that localtime returns a timestamp like "Thu May 13 20:26:09 2004", as it does in scalar context. This kind of trap is really dangerous, I think anyone learning Perl has fallen to it at least once. (The most dangerous are operations that have entirely different side effects in different contexts, like /g regexps.)
So, returning to the list functions, some of these have no meaning in scalar context (like sort, @arr[@inds], map), and Perl typically gives a warning whe you use them that way. Others are typically used in list context (grep, @array, stat, keys) so you would only use them in scalar context if you already expect some sort of behavior (that is, you have read the manual). Others are both used in list and scalar contexts equally often, like readline, readdir, m//g, the comma operator, the yadda-yadda operator; these really perform two different things in the two contexts. Yes, you have to know this type, but still, you won't probably get trapped by excepting something else as a scalar value if you only know the list value, only the other way round. (Well, maybe with m//g, yes.)