in reply to Re: Re: string context and list operators (was Re: Array in scalar context.)
in thread Array in scalar context.

1. Is a string context same as scalar context where the scalar value is "stringified" ? 2. Is a numeric context same as scalar context where the scalar value is turned to numeric so as to perform any numeric operation ? 3. Is a boolean context same as scalar context where the scalar value is booleanized ?

Sort of, but not really, or at least not always. perl may sometimes work that way internally, but I don't think of it that way in Perl as a language. In particular, some things return entirely different values depending on which type of scalar context they are in. For example, $! has magic that allows it to return an error number in numeric context but return an error description in string context. The description is not just an ordinary stringification of the number. Sure, $! is internal Perl magic, but see also the Want module, which allows user code to distinguish (e.g.) boolean context from other kinds of scalar context. There will be even more of this sort of thing in Perl6. Also, with regard to boolean context, it is noteworthy that some of the operators you might think of as boolean (&&, ||, and, or) do not supply boolean context to their operands, but rather a generic scalar context. (This is why $foo = $bar or $baz works the way you want.) The condition of an if clause does, however, supply boolean context, or such is my understanding.

4. (...) So the print function stringifies boolean true value of the expression $!>0 to "1" but why not the boolean false value 0 to "0" ?

I think false stringifies to the empty string.

my $bool = not (1==1);
if ($bool eq "") {
   print "False stringifies to the empty string.\n" 
} else { print "Nope.\n" }

[download]
Speaking conversly, is there any case where a numeric value in string context returns empty string ?

None that I'm aware of. Zero returns "0" in string context, of course. However, here are a couple of things that are fun to try... 

  my $bignum = 1000;
  for (1..1000) { $bignum *= $bignum }
  print "bignum is now $bignum\n";
  my $epsilon = 1/$bignum;
  print "epsilon is now $epsilon\n";

[download]

I could have sworn there used to be a way to get a result that was NaN (Not a Number), but I can't seem to find an example of that right now. Maybe it involved using a math module or something. All I get when I try to produce it is an error.

davido (in his earlier reply to this thread) mentions that "If you could call wantarray on print it would return true.

Yes, that's right, but...

print wantarray ? YES : NO , "\n";

Two things here: first, wantarray tells you what the current subroutine wants, and does not extend down to smaller constructs, which is why davido said, "if you could". Second, in the above code, you are not calling wantarray in the context that print supplies, but in the context that the trinary ?: operator supplies, which is scalar, so even if wantarray _did_ work on things smaller than subroutines (which it doesn't), that code still wouldn't do what you want.

When you said in your first reply that, "join function is a list operator, like print" are you refering to the syntactial behavior of print (because it can take an array as one of it's arguments)

print and join both take a flattened list; it is not quite right to say that either of them "can take an array as one of its arguments". Rather, either of them can take some of its arguments from an array. So, print @foo, @bar has the same effect as @args = @foo; push @args, @bar; print @args; and similarly with join. And yes, semantically they both then procede to treat the individual arguments (the _elements_ of the list they are passed) with a string context. This is not at all the same as treating the arrays in string context (which would count the elements in the array and stringify the resulting number).

split is an operator instead of a function. Can you please throw some light on this?

Well, in Perl you can use an operator as a function and vice versa... 

  my $foo = 3;
  my $x = print($foo) + 7;
  # There we used print (which is a list operator) as 
  # a function; it returns true, which in numeric
  # context is 1. $x is now 8
  print "\n";
  sub mult { # Declare a function...
    print "Entering function bar\n   1";
    # Here print is used as a statement.
    my $product = 1;
    for (@_) { 
       $product *= $_;
       print " * $_" }
    print " = $product\nExiting function bar\n";
    return $product;
  }
  print mult 42, $x;
  # Here print is used as a statement,
  # but mult (a function) is used as a list operator.
  print "\n";

[download]

If we wanted to be more clever, we could write our mult function so that in scalar context it returns the product, but so that in list context it would returns all the numbers and multiplication signs, equal sign, and product showing the whole multiplication. In Perl6 we'll be able to go one better and write it so that in numeric context it returns just the product, in list context all the numbers and the product, and in string context an equation showing the multiplication. Better, it could return a "multiplaction" object that knows how to represent itself in all of these ways on demand, so that we could call the function once, do something with the product immediately, but hang onto the whole problem and later reproduce the list of numbers that were multiplied together or if desired print out the whole equation. This sort of thing would be great e.g. if we were building a Huffman tree. (Okay, so that's addition not multiplication; anyway, Perl6 is going to be entirely too cool.)

So anyway, as I was saying, Perl blurs the distinction between operators and functions. In fact, I'm pretty sure you can use split as a function... 

print join "\n", 
        split(/\s+/,"Just Another Perl Hacker"),
        "\n";

[download]

So, without reading the larger context of the chapter, I'm not sure what point the author of Learning Perl was trying to make. (I've never read it. I started with Programming Perl.) 

int main()
{
   char buf[50];
    char a[] = {'a', 'b', 'c'};
    sprintf (buf, "Hello %s here\n", a);
    printf ("%s", buf);
}

[download]

Well, my knowledge of C is somewhat less advanced than my knowledge of Perl (translation: I don't know C worth beans), but my understanding is that you need one formatting code (e.g., %s) for each item you pass. Note that it is the formatting codes (e.g., "%s") that are the same as in Perl as in C. The call syntax for the function, of course, is different, to say nothing of the difference in the way strings are handled in general.

Can a Perl programmer code functions which do string magic like $! does?

In Perl5 I think that kind of magic requires XS. (i.e., you have to write part of your Perl module in C). However, you might look for existing modules, e.g., Want, which might (depending on what you need to do) save you from needing to write any XS yourself. Update: see tilly's better answer on this point. In Perl6 this will be improved further with the introduction of the new want builtin, which will replace wantarray and be much, much more general (and therefore will be much more useful).

If an array in scalar context returns it's length why wasn' the same thing done for lists as well?

I don't know why. It doesn't, though. A list in scalar context returns one element from the list. This might change in Perl6. Meanwhile, if you need a count of the number of items in a list, you can always throw it in an array. If you don't want to use a named array, you could use an anonymous array. 

my $count = @{[@foo, @bar, @baz]};
print "There are $count elements altogether between the three arrays.\
+n";

[download]

(But note that the above code makes a temporary copy of all three arrays, so if they have lots of elements it would be more efficient to call them in scalar context individually and add up the results.)

Is this due to a similar kind of reason such as sprintf style from C was not possible for hash interpolation?

I don't think so, but I don't know enough about C to be absolutely certain.

$count = () = $data =~ m/and/g;

I'm not sure exactly what's going on here. The () does, I think, cause the =~ operator to be in list context, but beyond that I'm not sure what magic causes $count to come out as a number instead of "and". It may be that what I'm missing has to do with the difference between m/foo/g and s/foo/bar/g. The latter I use much more frequently than the former, but they work differently. I'll try to remember to look into that and reply again if I figure out exactly what's going on there. 

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

[download]

Replies are listed 'Best First'.
Re: Re: string context and list operators (was Re: Array in scalar context.)
by tilly (Archbishop) on Oct 13, 2003 at 03:25 UTC
    In Perl5 you certainly can get $!-like magic in pure Perl.

    See overload.

[reply]
Re: Re: string context and list operators (was Re: Array in scalar context.)
by Anonymous Monk on Oct 18, 2003 at 20:46 UTC
    Thanks again for your reply. Since I am new to PERL it takes a long time to go through the responses and understand them. Once again here are my questions. Thanks for your help.

    1. On wantarray/want and context

    (a) what I understand by the definition of wantarray
    The wantarray function can be used inside of a subroutine definition to determine the context in which that subroutine is called. By default, such a context is available to the return statement of the subroutine. But if the context is to be known in other parts of the definition of the subroutine then wantarray needs to be used. Is this observation true ? Is the real usage of wantarray just limited to using inside of a subroutine ?

    (b) In the program, 

    sub test_wantarray{
   wantarray ? Y : N;
}

print "Hello" . &test_wa . "World\n";
print "Hello", &test_wa, "World\n";

    [download]
    output: 
    HelloNWorld
HelloYWorld

    [download]
    In the first print function, the concatenation operator supplies the context to subroutine test_wantarray. Hence wantarray from inside of test_wantarray finds this context to be a scalar context and returns N. In the second print function, since the comma operator (,) doesn't supply a context of it's own, the subroutine test_wantarray is operating under the context supplied by print function. Hence wantarray from inside of test_wantarray finds this context to be list context and hence returns Y. Is this what davido meant by "IF YOU COULD call wantarray on print function it would return true." and am I successful in calling wantarray on print function (i.e. in the case of second print function)?

    (c) Since the above subroutine test_wantarray is just one line, if the subroutine call is replaced in the above print function to be, 

    print "Hello", (wantarray ? Y : N), "World\n";

    [download]
    it prints: HelloNWorld. Is it that wantarray can only be used inside a subroutine? Can you explain about what you mentioned earlier? i.e. "you are not calling wantarray in the context that print supplies, in the context that ternary operator supplies" ?

    If the ternary operator context is scalar how can it return a list if the expression for this ternary operator evaluates to true and an array is to be returned? i.e. in cases such as, 
    sub test_wantarray{
wantarray ? @array: \@array;
}

    [download]
    Why this scalar context of ternary operator doesn't come into play inside of the subroutine test_wantarray ?

    (d) Refering to the print function in the above sub section (b) 

          print "Hello", &test_wa, "World\n";

    [download]
    returns true confirming that the print function is providing a list context to it's arguements. If such is the case,
    why provide a list context to it's arguments only to see to it that print cannot operate on them (or rather it has to flattens them)? Why not just provide a "flattened list context" where the argument list/array isn't seen but only the individual elements within the list/array ? i.e. in your earlier reply you mentioned "print and join both take a flattened list". What am I missing here ?

    (e) I looked at want module documentation (http://dev.perl.org/perl6/rfc/21.html) but wasn't able to understand. Is the real use of this,

    (i). want should be able to distinguish between various type of scalar contexts or various type of list contexts when used inside of a subroutine . Can you please provide an example ?
    (ii). how does it get down to small constructs (as opposed to wantarray) ? Can you please provide an example ?

    2. If the return value of an expression is, undef or "" or number 0 would they all evaluate to false value in boolean context?

    3. Can we confirm from the below program that, the internal value of undef is the ASCII null value (ie. ASCII code: 0) 

    if (undef eq "")
{
 print "undef evaluates to empty string in string context\n";
}
if (undef == 0)
{
 print "undef evaluates to zero in numeric context\n";
}

    [download]

    4. In the below code 

    $count = () = $s =~ /abc/g;

    [download]
    Did you get any chance to find out what exaclty causes $count to return the number of times abc appears in $s instead of  abcwhen you mentioned that "....I'm not sure what magic causes $count to come out as a number instead of "abc". It may be that what I'm missing has to do with the difference between m/foo/g and s/foo/bar/g. The latter I use much more frequently than the former, but they work differently. I'll try to remember to look into that and reply again if I figure out exactly what's going on there."

    5. Just wanted to know, where did you come accross the information that your earlier mentioned i.e. "....way back in the day it was decided that the array interpolation inside double quoted string should have the same syntax as that of sprintf of C. So when array interpolation was added, hash interpolation along the same lines couldn't be. This will be remedied in PERL 6....". I just needed this detail just to understand why hash interpolation couldn't be added.

[reply]
[d/l]
[select]
      The wantarray function can be used inside of a subroutine definition to determine the context in which that subroutine is called.

      Yes, exactly.

      By default, such a context is available to the return statement of the subroutine.

      Well, you could view it that way, insofar as whatever expression you are returning (either by explicit return or implicitely by virtue of its being the last thing evaluated in the function) will be evaluated in the supplied context, yes. But if you want to return something entirely different in different contexts, then you use wantarray (or, in Perl6, want).

      Is the real usage of wantarray just limited to using inside of a subroutine?

      Yes, wantarray tells you the context in which the current routine was called. Now, that routine can be a named sub, or it can be an anonymous sub ("closure"), or a method. In Perl6 it can also be a multimethod or (I think) a rule. All of these you can think of as one type or another of subroutine, so the statement "wantarray tells you the context in which the current subroutine was called" still holds true irrespective of which exact type of subroutine that is. 

      sub test_wantarray{
   wantarray ? Y : N;
}

print "Hello" . &test_wa . "World\n";
print "Hello", &test_wa, "World\n";

output:

HelloNWorld
HelloYWorld

      [download]
      In the first print function, the concatenation operator supplies the context to subroutine test_wantarray. Hence wantarray from inside of test_wantarray finds this context to be a scalar context and returns N.

      Yes, exactly.

      In the second print function, since the comma operator (,) doesn't supply a context of it's own, the subroutine test_wantarray is operating under the context supplied by print function. Hence wantarray from inside of test_wantarray finds this context to be list context and hence returns Y.

      Basically, yes. Some people will tell you that there are two different comma operators, one that operates in scalar context and one that operates in list context, but even if you view it that way, it is still true that the list context is present because that is what print supplies; if you were to replace print with a function that supplies scalar context, test_wa would not be called in list context. (Actually, it would be called in void context, because only the last value of the "list" would be wanted. People who believe in two different comma operators would say that the scalar comma always supplies void context to its left operand. I prefer to think that Perl knows only the last value of the list is wanted and evaluates the others in void context. Either way, test_wa is called in void context.) 

        sub print_context {
    if (not defined wantarray) {
      print "[void context]";
    } elsif (wantarray) {
      print "[list context]";
    } else {
      print "[scalar context]";
    }
    return undef;
  }
  "Hello", print_context, "World\n";               # void context
  print "\n";
  "Hello " . print_context . "World\n";            # scalar context
  print "\n";
  print "Hello " . print_context . "World\n";      # scalar context
  print "\n";
  print "Hello", print_context, "World\n";         # list context
  print "\n";
  join print_context,                              # scalar context
    print_context, print_context;                  # both list context
  print "\n";

      [download]
      Is this what davido meant by "IF YOU COULD call wantarray on print function it would return true."

      Yes.

      and am I successful in calling wantarray on print function (i.e. in the case of second print function)?

      Indirectly, yes.

      Since the above subroutine test_wantarray is just one line, if the subroutine call is replaced in the above print function to be, print "Hello", (wantarray ? Y : N), "World\n"; it prints: HelloNWorld. Is it that wantarray can only be used inside a subroutine?

      Yes. If you put that code inside a subroutine, it will print something different depending on the context in which you call that subroutine.

      Can you explain about what you mentioned earlier? i.e. "you are not calling wantarray in the context that print supplies, in the context that ternary operator supplies"?

      I was talking about the same thing you were just now talking about: wantarray takes its notion of context from the current routine, not necessarily the immediate local grammatical construct. This is actually useful; if wantarray took its notion of context from the immediate context, you would not be able to test it easily, because your test condition would always supply a boolean context. For example if we had a mythical immediate_context operator that returned the immediate context in which it was called, and we tried to use it, ... print (immediate_context?"list":"scalar or void"); we would always get "scalar or void", even though print supplies a list context, because the trinary operator (foo?bar:baz) supplies boolean context (which is a type of scalar context) to its leftmost operand. So, ... 

        print_context() ? print_context() : print_context();
  print "\n";

      [download]

      This prints "[scalar context][void context]", because the boolean context in which the first print_context is called is scalar, and so the second one (between the ? and the :) is not called, and the third is called in void context.

      If the ternary operator context is scalar how can it return a list if the expression for this ternary operator evaluates to true and an array is to be returned? i.e. in cases such as, 
      sub test_wantarray{
wantarray ? @array: \@array;
}

      [download]

      The trinary operator supplies boolean context to its leftmost operand. The middle or right operand (whichever is evaluated) is evaluated in the context inherited from the context in which the whole expression is found. In this case, the expression is the last thing evaluated in the subroutine, so it is an implicit return, and so it inherits the context in which the routine was called. Try these: 

        print_context() ? print_context() : print_context();
print "\n";
print print_context() ? print_context() : print_context();
print "\n";
print join(print_context() ? print_context() : print_context()), print
+_context(), "\n";

      [download]
      Refering to the print function in the above sub section (b) print "Hello", &test_wa, "World\n"; returns true confirming that the print function is providing a list context to it's arguements. If such is the case, why provide a list context to it's arguments only to see to it that print cannot operate on them (or rather it has to flattens them)? Why not just provide a "flattened list context" where the argument list/array isn't seen but only the individual elements within the list/array ? i.e. in your earlier reply you mentioned "print and join both take a flattened list". What am I missing here ?

      Flattening. Just as an array is in this context not a single argument, but is "flattened" into its elements, so also a subroutine call is "flattened" into as many elements as it can provide, which all become part of the list that the function (in this case print) sees. This happens anytime a function calls for a flat list, which is the default for all functions that do not explicitely set a different prototype.

      I looked at want module documentation (http://dev.perl.org/perl6/rfc/21.html) but wasn't able to understand. Is the real use of this,

      This "documentation" you were looking at was someone's suggestion (Damian Conway's suggestion, as it happens) for how things ought to be in Perl6. If you want to see the answer to this suggestion, and an explanation of how this will actually be in Perl6, see Apocalypse 6. For a simpler explanation (by, as it happens, the same Damian Conway who wrote the suggestion you looked at), see Exegesis 6.

      If what you wanted was the documentation for the Want module for Perl5, you want to look for it on search.cpan.org (which is, generally, the best place to find documentation for many modules).

      If the return value of an expression is, undef or "" or number 0 would they all evaluate to false value in boolean context?

      Yes. undef, "", and 0 are all false in boolean context. Also, "0" if I am not mistaken is false in boolean context. However, "0.0" or "0 but true" (as strings) are true. Also, a list containing a single value which is undef is true. When undef is the entire list, it is considered to be a list containing no elements, and _that_ would be false, but if undef is an element in the list, then the list contains elements (at least one element) and therefore is true. Usually, this is all exactly what you would intuitively think, but occasionally it can be handy to know exactly what is what.

      Can we confirm from the below program that, the internal value of undef is the ASCII null value (ie. ASCII code: 0)

      Not necessarily. For one thing, the ASCII null in Perl does not have the same semantics in a string as it does in C. It is just another character, in fact, with no special meaning at all to Perl. I believe undef in Perl is like nil in lisp: it is a value in its own right, distinct from other values such as zero. (Also, it may not be entirely a conincidence that both undef in Perl and nil in lisp are synonymous with an empty list containing no elements. Perl probably borrowed this idea from lisp or one of its derivatives.) The reason it evaluates to the empty string in string context and zero in numeric context is because Larry Wall thinks (probably rightly) that this is the least unexpected thing for it to do in those circumstances, not because of the way it is stored internally. Perl, generally, tries to do what is right, or what is wanted, or what makes sense, rather than basing its behavior on lowlevel implementation details. There are places where the implementation details leak through, but I do not think this is one of them.

      $count = () = $s =~ /abc/g;

      I still intend to get to that...

      Just wanted to know, where did you come accross the information that your earlier mentioned i.e. "....way back in the day it was decided that the array interpolation inside double quoted string should have the same syntax as that of sprintf of C. So when array interpolation was added, hash interpolation along the same lines couldn't be. This will be remedied in PERL 6....". I just needed this detail just to understand why hash interpolation couldn't be added.

      Several different sources. The information about sprintf I've had in my head for some time and am not sure exactly when or where I discovered it. My 2nd edition Camel book mentions that sprintf formattiong codes work the same way in Perl as in C, but somewhere along the line I believe I have been told by someone that this was present in Perl4. As far as arrays not interpolating in older versions of Perl, I picked this up when I was new, by trying this:

      print "jonadab@bright.net";

      In Perl 5.0 through 5.6, this will give you an error, telling you that the @ symbol needs to be escaped; in 5.8, it no longer does this (though if you use warnings you will get a "Possible unintended interpolation" warning). But in 5.0 this behavior was new, and so the error message was included so people would know what was going on when they got "jonadab.net" and wondered where the rest of their email address went. The information about Perl6 mostly comes from reading the Apocalypse articles and to a lesser extent the perl6-language mailing list. I think I may also have picked up from the Perl6 sources the idea that hash interpretation was not possible in Perl5 because it would conflict with the sprintf syntax, or I may have figured that out on my own. If you think about it, it's obvious that if printf "%02d", 3 gives you "03", then it can't also interpolate the hash named %02d. But in Perl6, printf will be handled another way, or such is my understanding, based on Apocalypse 2. 

      $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

      [download]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom