The simplest answer to the question is 'it depends'. However, there are a couple of things that I started doing fairly early on in my use of perl. The first is that in most cases, subs that wishes to utilise the calling context to differeciate what they return, should probably be testing for context as the (one of) the first things they do, rather than leaving it as something done on the return line. If the natural scalar context of a sub that can return a list is to return only the size of the list, then there is some economy in knowing that up front. It's inherently cheaper to increment a count for return than to accumulate an array and then discard it and only return the size. Equally, if a sub is called in a void context it is better to to return immediatly having done nothing rather than do stuff and then throw it away. If the sub has side effects and only returns a status value, then if called in a void context, it can be nice to have a (configurable) option to die if the sub fails -- I wish that this was an option for many of the built-in subs.

I don't view the use of context as being unique to perl, although the way it is manifest in other languages is somewhat different. In C++ for example, it could be argued that the incorporation of a methods return type into the method signature is a form of context. The difference is that it is handled entirely by the compiler rather than by the programmer.

One arguement for this approach is that it removes one detail from the auspices of the programmer and is therefore a good thing.

However, an alternative view is that this then requires the programmer to code multiple methods, one for each possible context, and/or requires the use of explicit casting.

Far from being a failed experiment, I think that context is a potentially very useful feature of perl that is only let down by it's currently limited form. IMO there are three limitatations to the current mechanism.

1. The number of detectable contexts is too limited with just void, scalar and list.

   I would like to see this extended by

   • The subdivision of scalar context into string and numeric. And the numeric context subdivided into integer and real.
   • List context should be subdivided into list, array and hash context.
   • The addition of a "reference" context.
   • The addition of an "alias" context.
2. The inconsistancy with which the current contexts are interpreted by implementers and implementations, not least by perl itself.
3. The limitations and inconsistancies of the perl prototyping mechanism.

From what I've seen of P6, all three of these are being addressed in ways that hopefully will make the whole concept of contexts become more useful and consistant. Who knows, maybe they will prove to be so useful that other languages might copy the idea in the future.