Re: Scalars, Lists, and Arrays

Boolean context is ubiquitous, so let's give this little brother of list and scalar its due!

"Boolean context" is 100% identical with scalar context. It is a fiction.

Interpolative context

That is not a context, because expressions are not evaluated in double-quoted strings. What value does localtime() produce in "The time is: localtime()\n"?

Void context

This one is a little different. For built-in Perl operators, it's identical to scalar context. The only time it might be different is for a user-defined function that explicitly tests whether wantarray yields an undefined value, and which does something different if so. Regardless, there's no question about what the return value is.

The interesting one I think you left out is that the argument of defined is a different kind of context. defined(&foo) doesn't even call &foo.

Comment on Re: Scalars, Lists, and Arrays

Replies are listed 'Best First'.
(tye)Re4: Scalars, Lists, and Arrays by tye (Sage) on Apr 13, 2001 at 22:54 UTC
sigh let's not go overboard on what can and can't be called a "context", either. So-called "Boolean context" is a useful concept, especially if you are dealing with overloaded objects. I agree that it is important to realize that it isn't a "context" in the same way that "scalar context", "list context", and "void context" are and that using something in a "Boolean context" is hard to distinguish from using it in a scalar context (though it can be done by using overloading). I'd love to see an enhancement that elevates "Boolean context" to being a "first class context" (well, at least "second class" if you don't count "void" as "first class") by, for example, adding a OPf_WANT_BOOL flag. "Interpolative context" can also be a valuable concept for explaining why these are different: `print "@a"; print "".@a; print @a;` [download] even though it is very much different than the "big three" contexts. This one reminds me of the "numeric", "string", and "integer" pseudo contexts. For built-in Perl operators, [void context] is identical to scalar context Doing a quick search, I found that keys knows the difference between scalar and void context so that it can avoid some work in the latter case. I suspect there are more than a few other cases. I'm not trying to contradict you, I just don't want others to overinterpret what you are saying. I guess that by "do something different" (in the case of a user-defined function detecting void context) you are referring to "side effects" and that you are asserting that no built-in functions/operators of Perl have different side effects between scalar and void context. I would certainly be somewhat surprised to find a case that violates such an assertion but I wouldn't feel comfortable making that assertion myself. I'd take issue with your using "context" to describe the special way defined works but that would just seem ornery of me. A similar "context" that I'm finding increasingly interesting is the "pseudo code block context" that is given to the first argument of map or grep: `map func($_), @list; grep func($_), @list;` [download] - tye (but my friends call me "Tye")	[reply] [d/l] [select]

Replies are listed 'Best First'.

(tye)Re4: Scalars, Lists, and Arrays
by tye (Sage) on Apr 13, 2001 at 22:54 UTC

*sigh* let's not go overboard on what can and can't be called a "context", either.

So-called "Boolean context" is a useful concept, especially if you are dealing with overloaded objects. I agree that it is important to realize that it isn't a "context" in the same way that "scalar context", "list context", and "void context" are and that using something in a "Boolean context" is hard to distinguish from using it in a scalar context (though it can be done by using overloading). I'd love to see an enhancement that elevates "Boolean context" to being a "first class context" (well, at least "second class" if you don't count "void" as "first class") by, for example, adding a OPf_WANT_BOOL flag.

"Interpolative context" can also be a valuable concept for explaining why these are different:

print "@a";
print "".@a;
print @a;
[download]

For built-in Perl operators, [void context] is identical to scalar context

Doing a quick search, I found that keys knows the difference between scalar and void context so that it can avoid some work in the latter case. I suspect there are more than a few other cases. I'm not trying to contradict you, I just don't want others to overinterpret what you are saying.

I guess that by "do something different" (in the case of a user-defined function detecting void context) you are referring to "side effects" and that you are asserting that no built-in functions/operators of Perl have different side effects between scalar and void context. I would certainly be somewhat surprised to find a case that violates such an assertion but I wouldn't feel comfortable making that assertion myself.

I'd take issue with your using "context" to describe the special way defined works but that would just seem ornery of me. A similar "context" that I'm finding increasingly interesting is the "pseudo code block context" that is given to the first argument of map or grep:

map func($_), @list;
grep func($_), @list;
[download]

tye

[reply]
[d/l]
[select]