|
in reply to If you believe in Lists in Scalar Context, Clap your Hands
So, what value do you see in advocating this model?
I prefer to stick to models that, well, model what actually happens. And what actually happens
is that the , operator really does have a scalar-context mode that gives the left operand void
context and the right operand scalar context.
However, in the case of a literal list returned by a sub, there are complications. Context in perl
is somewhat limited. It can either be derived at compile time or looked up at runtime. If the latter,
it is the context in which the current sub, eval, or mainline code is called (which itself may or may not be known at compile time).
But this isn't complex enough to fully handle a literal list. When a literal list
appears in list context, each component should have list context. This works fine.
When a literal list appears in void context, each component should have void context.
This also works fine. But when a literal list appears in (not known at compile time)
scalar context, every component but the last should have void context. And perl's
context propagation isn't smart enough for that. Instead every component gets scalar
context and a cleanup operator (named "list") ensures that in fact the list of results is reduced
to the last scalar. This is quite clearly a case of a list in scalar context.
The following code demostrates this, using a tied array as a left operand to a comma operator in each of void, scalar, and list context, first where the context is known at compile time, and then where it isn't:
$ perl
$ perl
use Tie::Array;
@ISA="Tie::StdArray";
sub FETCHSIZE{print "in FETCHSIZE\n";my $self=shift;$self->SUPER::FETC
+HSIZE(@_)};
tie @x,"main";
@x=1..3;
print "void\n"; @x,1;
print "scalar\n"; $x=(@x,1);
print "list\n"; ()=(@x,1);
print "void\n"; sub{@x,1}->();
print "scalar\n"; $x=sub{@x,1}->();
print "list\n"; ()=sub{@x,1}->();
__END__
void
scalar
list
in FETCHSIZE
void
scalar
in FETCHSIZE
list
in FETCHSIZE
Note that where the scalar context is known at compile time, the left operand to , got void context, but where it was not known, it got scalar context.
|
Re^2: If you believe in Lists in Scalar Context, Clap your Hands
by BrowserUk (Patriarch) on Oct 28, 2008 at 06:12 UTC
|
I prefer to stick to models that, well, model what actually happens.
If that works for you, then that is exactly what you should do.
But, you are very much "in the know", about the perl internals. This allows you to have a model that reflects "what actually happens". This is clearly not the case for everyone.
Not even those ranked amongst those who are in a position to know, given the contradiction between your statement a little further down: "This is quite clearly a case of a list in scalar context.", and that other "in the know" stance frequently repeated in this thread and it's predecessor.
So, what value do you see in advocating this model?
In a phrase: Conceptual simplicity.
In an attempt to back that reasoning up, I quote a few selected passages* from Chapter 7:"Being Analog of a book, The Invisible Computer by Donald Norman a professor emeritus in cognitive science and a Professor of Computer Science.
(*)I'd like the quote the whole chapter, and highly recommend the entire book.
Making Sense of the World
If an airplane crashes on the border between the United States and Canada, killing half the passengers, in which country should the survivors be buried?
We are social creatures, understanding creatures. We try to make sense of the world. We assume that information is sensible, and we do the best we can with what we receive. This is a virtue. It makes us successful communicators, efficient and robust in going about our daily activities. It also means we can readily be tricked. It wasn't Moses who brought the animals aboard the ark, it was Noah. It isn't the survivors who should be buried, it is the casualties.
It's a good thing we are built this way: this compliance saves us whenever the world goes awry. By making sense of the environment, by making sense of the events we encounter, we know what to attend to, what to ignore. Human attention is the limiting factor, a well known truism of psychology and of critical importance today. Human sensory systems are bombarded with far more information than can be processed in depth: some selection has to be made. Just how this selection is done has been the target of prolonged investigation by numerous cognitive scientists who have studied people's behavior when overloaded with information, by neuroscientists who have tried to follow the biological processing of sensory signals, and by a host of other investigators. I was one of them: I spent almost ten years of my research life studying the mechanisms of human attention.
One understanding of the cognitive process of attention comes from the concept of a "conceptual model," a concept that will gain great importance in Chapter 8 when I discuss how to design technology that people can use. A conceptual model is, to put it most simply, a story that makes sense of the situation.
I sit at my desk with a large number of sounds impinging upon me. It is an easy matter to classify the sounds. What is all that noise outside? A family must be riding their bicycles and the parents are yelling to their children. And the neighbor's dogs are barking at them, which is why my dogs started barking. Do I really know this? No. I didn't even bother to look out the window: my mind subconsciously, automatically created the story, creating a comprehensive explanation for the noises, even as I concentrated upon the computer screen.
How do I know what really happened? I don't. I listened to the sounds and created an explanation, one that was logical, heavily dependent upon past experience with those sound patterns. It is very likely to be correct, but I don't really know.
...
A good conceptual model of events allows us to classify them into those relevant and those not relevant, dramatically simplifying life: we attend to the relevant and only monitor the irrelevant. Mind you, this monitoring and classification is completely subconscious. The conscious mind is usually unaware of the process. Indeed, the whole point is to reserve the conscious mind for the critical events of the task being attended to and to suppress most of the other, non-relevant events from taking up the limited attentional resources of consciousness.
On the whole, human consciousness avoids paying attention to the routine. Conscious processing attends to the non-routine, to the discrepancies and novelties, to things that go wrong. As a result, we are sensitive to changes in the environment, remarkably insensitive to the commonplace, the routine.
Conceptual models do not always have to be total accurate. Indeed, they frequently benefit from not being so.
Would you trade your own understanding of 'right and wrong', for having to know and remember the entire corpus of 'The Law' applicable to you and your actions, and to which you may be held to account. There's an axiom that goes: "Ignorance of the law is no defence.". So how can any of us hope to know every law: federal, local, commercial, moral; to which we are subject?
And the answer is we cannot. Instead we make do with a conceptual model--for example: would we be upset if someone did this to us?, If so, don't do it to others--that we hope stands us in good stead in most situations.
Some would advocate that this ambiguity, the very need for conceptual simplification, is reason enough to avoid reliance upon Perl's more magical features. Some would even advocate that the entire concept of context should be dropped as too complex. Preferring instead some quantified set of rules for how the language operates and how it should be used. I can only refer them to a later section, "Human Error", of Chapter 7 linked above, where it says:
Programming languages are difficult to learn, and a large proportion of the population is incapable of learning them. Moreover, even the most skilled programmers make errors, and error finding and correction occupy a significant amount of a programming team's time and effort. Moreover, programming errors are serious. In the best circumstances, they lead to inoperable systems. In the worst, they lead to systems that appear to work but produce erroneous results.
A person's first human language is so natural to learn that it is done without any formal instruction: people must suffer severe brain impairment to be incapable of learning language. Note that "natural" does not mean "easy": it takes ten to fifteen years to master one's native language. Second language learning can be excruciatingly difficult.
Natural language, unlike programming language, is flexible, ambiguous, and heavily dependent on shared understanding, a shared knowledge base, and shared cultural experiences. Errors in speech are seldom important: Utterances can be interrupted, restarted, even contradicted, with little difficulty in understanding. The system makes natural language communication extremely robust.
Natural language is full of context. It relies upon it for it's robustness. Perl (5; 6 is still an open question) approaches the level of flexibility, ambiguity and yes, "even contradiction" of natural languages more closely than any other I've knowledge of. You can pick up the basics through osmosis just as a child does with their native language, but to acquire fluency requires long term immersion.
And that final point is why this site could never be replaced with a static corpus of POD, FAQs, and best practices. A couple more quotes:
The United States Navy has a formal, rigid hierarchy of command and control, with two classes of workers -- enlisted crew and officers -- and a rigid layer of formal rank and assignment. There are extensive procedures for all tasks. Yet in their work habits, especially in critical operations, rank seems to be ignored and crew members frequently question the actions. Sometimes they even debate the appropriate action to be taken. The crew, moreover, is always changing. There are always new people who have not learned the ship's procedures, and even the veterans often don't have more than two or three year's experience with the ship: the Navy has a policy of rotating assignment. Sounds horrible, doesn't it? Isn't the military supposed to be the model of order and structure? But wait. Look at the outcomes: the crew functions safely and expertly in dangerous, high-stress conditions. What is happening here?
Do we need procedures? Of course. The best procedures will mandate outcomes, not methods. Methods change: it is the outcomes we care about. Procedures must be designed with care and attention to the social, human side of the operation. Else we have the existing condition in most industries. If the procedures are followed exactly, work slows to an unacceptable level. In order to perform properly it is necessary to violate the procedures. Workers get fired for lack of efficiency, which means they are subtly, unofficially encouraged to violate the procedures. Unless something goes wrong, in which case they can be fired for failure to follow the procedures.
Now look at the Navy. The apparent chaos, indecision and arguments are not what they seem to be. The apparent chaos is a carefully honed system, tested and evolved over generations, that maximizes safety and efficiency even in the face of numerous unknowns, novel circumstances, and a wide range of skills and knowledge by the crew. Having everyone participate and question the actions serves several roles simultaneously. The very ambiguity, the continual questioning and debate keeps everyone in touch with the activity, thereby providing redundant checks on the actions. This adds to the safety, for now it is likely for errors to get detected before they have caused problems. The newer crew members are learning, and the public discussions among the other crew serve as valuable training exercises, training mind you not in some artificial, abstract fashion, but in real, relevant situations where it really matters. And by not punishing people when they speak out, question, or even bring the operations to a halt, they encourage continual learning and performance enhancement. It makes for an effective, well-tuned team.
New crew members don't have the experience of older ones. This means they are not efficient, don't always know what to do, and perform slowly. They need a lot of guidance. The system automatically provides this constant supervision and coaching, allowing people to learn on the job. At the same time, because the minds of the new crew members are not yet locked into the routines, their questioning can sometimes reveal errors: they challenge the conventional mindset, asking whether the simple explanation of events is correct. This is the best way to avoid errors of misdiagnosis.
The continual challenge to authority goes against conventional wisdom and is certainly a violation of the traditional hierarchical management style. But it is so important to safety that the aviation industry now has special training in crew management, where the junior officers in the cockpit are encouraged to question the actions of the captain. In turn, the captain, who used to be thought of as the person in command, with full authority, never to be questioned, has had to learn to encourage crew members to question their every act. The end result may look less regular, but it is far safer.
This place, and especially threads like this, are exactly why this place works, It is exactly this type of debate, all too often stifled, that turns drive-by questioners into long-term, active participants. (And it should be encouraged, not frowned upon.)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
So, what value do you see in advocating this model? In a phrase: Conceptual simplicity.
That's the obvious answer. But I was hoping for more of a demonstration of benefit in the answer.
Simplicity has positives and negatives, as well as various levels. On the simplest level, you can
think of perl having both scalar and list values, and describe what different operations do with
them. I think this encourages mistakes like $foo{bar} = (1,2,3); and @baz = [1,2,3];. The biggest reason I see for moving to a less simple (but still inaccurate!) model of "no such thing as a list in scalar context" is that I think it encourages more of an "operators provide context to their operands" pattern of thought that is the basis for really understanding what you are doing when you code perl. Of course, it would be great if everyone could shed even that level of simplicity, but that's asking a bit much.
| [reply]
[d/l]
[select] |
|
|
That's the obvious answer.
Outside of women's fashion, I don't see much wrong with the obvious :)
Beyond the obvious, because a simpler story makes for easier learning.
For the proof of that, you'd have to read the quotes, and preferably the whole chapter they were drawn from. He makes the case better than I ever could. In particular, see the "French air-traffic controller" example to see how the ridged application of correctness can take a disastrous toll on productivity.
The 'no such thing' model just doesn't stand up to either the novice users hands-on perceptions: print scalar ('a','b','c');, even if that perception were technically flawed--which by your own testimony it isn't--or the reality.
If you're going to go with a known-flawed model, then go with one that fits the users perceptions, and allow them to become aware of and compensate for it's imperfections, as the need arises. Rather than a model that contradicts their perceptions, and requires them to make a huge leap of (either acquired or actual), knowledge, in order to become comfortable with it. Especially as they will have to unlearn either at some future point.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
|
|
|
|
Of course, it would be great if everyone could shed even that level of simplicity ...
In a word, "why"? Why would it be great if everyone learned what happens when perl interprets Perl even past that point? Why is that condition so obviously better than allowing people to get work done with a tool without understanding how the tool is built that you feel the need to say, "Of course"?
Isn't the point of having the tool so that the users don't need to think about the lower level while they are using it? Sure, it's beneficial for people who use a tool often for big projects to understand the tool and even to be able to improve the tool. However, most people who use a tool never build or modify the tool itself. This is not true of only software.
Do you drive? Can you adjust the valve timing on your car? Have you hung a picture? Have you ever made a hammer? Did you build your own kitchen cabinets or your own bed? Can you build and repair a refrigerator so that you can keep food cold?
Is the "operators provide context to their operands" pattern of thought really what all programmers are doing when they program in Perl, or is it something perl does for them so they don't have to worry about it?
| [reply] |
|
|
|
|
|
|
|
|
|
|
Nice post. Thank you for taking the time to write it.
When this particluar discussion started, I must admit that I found it a bit ridiculous. Lists in scalar context?? What?? That just didn't make sense to me at an intuitive level. But, after following the posts here, I now have a greater insight into the way some other people have structured their programming paradigms and I expect that this insight will prove helpful to me when communicating with other programmers.
This is the sort of discussion that sets PerlMonks apart from other programming sites and I applaud those who have taken part and cogently explained their views.
| [reply] |
|
|
