http://www.perlmonks.org?node_id=347663


in reply to Re: On Scalar Context
in thread On Scalar Context

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.


---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi


Replies are listed 'Best First'.
Re: Re: Re: On Scalar Context
by flyingmoose (Priest) on Apr 23, 2004 at 18:38 UTC
    This is a problem with the Perl mindset. DWIM has no value when "Do What I Mean" means different things to different people. Hence, there should be well defined concepts mandating that methods that normally output an array shouldn't do things that vary behavior based on the LHS. Most languages don't have return-type overloading with the same arguments, and I consider this a good thing. Perl, somehow, thinks it is different. I love Perl, but I don't believe in covering for it's faults -- or saying that the faults are really DWIMerry or features.
      Most languages don't have return-type overloading with the same arguments, and I consider this a good thing.

      Why?

      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 ) )[0] 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.