Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Scalars, Lists, and Arrays

by Dominus (Parson)
on Apr 13, 2001 at 21:02 UTC ( [id://72397]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: Scalars, Lists, and Arrays
in thread Scalars, Lists, and Arrays

Says sierrathedog04:
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.

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;
    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;

            - tye (but my friends call me "Tye")

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://72397]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2024-04-24 08:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found