Re: Puzzling $| behavior

Yesterday I wrote the following "opinion":

| print gets its "arguments in reverse order", similar to C.
| The above call would (in C) look like
|(pseudocode):

| ...
| XPUSH( "\n" );
| XPUSH( $| );
| $|--;               # plus true/false magic
| XPUSH( "second=" );
| XPUSH( $| );
| XPUSH( "first=" );
| PUTBACK;
| call_pv("print", G_ARRAY);
| ...

|^{(please correct here me if I'm wrong)}

which turned out to be completely wrong.
After reading the other posts and looking further
into the topic, I came to the conclusion that perl
evaluates the argument list before calling into a sub-
routine always left-to-right.

This can be shown by reading the deparsed output
from B::Bblock /1/. If used on the following lines:

1:     $| = 1;
2:     print "first=", $|, " second=", $|--, "\n";
[download]

the important output will be:

  OP (0x824de58) enter
  COP (0x81f3290) nextstate
#1   $| = 1
  SVOP (0x824dc80) const [6] IV (0x8167cdc) 1
  PADOP (0x818ae48) gvsv  GV (0x8168894) *|
  BINOP (0x8189398) sassign
#
  COP (0x824c638) nextstate
  OP (0x8250178) pushmark
# 2
  SVOP (0x8189428) const [7] PV (0x816881c) "first="
  PADOP (0x818c6f0) gvsv  GV (0x8168894) *|
  SVOP (0x818de00) const [8] PV (0x8168828) " second="
  PADOP (0x824ff88) gvsv  GV (0x8168894) *|
  UNOP (0x824fe50) postdec [4]
  SVOP (0x824de38) const [9] PV (0x81688b8) "\n"
  LISTOP (0x8250150) print
#
  LISTOP (0x824dac0) leave [1]
[download]

from where it can be learned that the $| decrement
occurs (postdec [4]) where it should.

Sorry for writing such a mess without checking before :-(

Regards

mwa

/1/ perl -MO=Bblock mysource.pl

Comment on Re: Puzzling $\| behavior Select or Download Code

Replies are listed 'Best First'.
Re^2: Puzzling $\| behavior by blokhead (Monsignor) on Oct 08, 2007 at 05:23 UTC
(please correct here me if I'm wrong) I don't know if perl's documentation defines (as a feature) the order in which arguments are evaluated, but it's simple to check that it really does evaluate them in left-to-right order: `$ perl -le 'print sub{print 1; "x"}->(), sub{print 2; "y"}->()' 1 2 xy` [download] The reason the OP's example is weird is because Perl's argument passing uses aliases whenever possible (as ikegami illustrates below). In the example, an alias to $\| gets passed as the second argument. When evaluating the fourth argument, $\| is changed. When print finally inspects its arguments, the aliased second argument will report the changed value. blokhead	[reply] [d/l]
Re^3: Puzzling $\| behavior by ikegami (Patriarch) on Oct 08, 2007 at 05:54 UTC
I don't know if perl's documentation defines (as a feature) the order in which arguments are evaluated It's not, but no one has mentioned a system or version where the arguments are evaluated in any order other than left-to-right in past discussions on the subject. It's technically subject to change since it's not documented, but I find it highly unlikely to change in Perl5.	[reply]
Re^4: Puzzling $\| behavior by mwah (Hermit) on Oct 08, 2007 at 10:35 UTC
ikegami: no one has mentioned a system or version where the arguments are evaluated in any order other than left-to-right My answer to the OP was completely wrong, which is what I found out after investigating into the topic. Thats another case where prejudice brings ill-fated conclusions. One simple look into `perl -MO=Bblock thisprog.pl` reveals the left-to-right sequence OP (0x824dc78) enter COP (0x81f30f0) nextstate SVOP (0x824daa0) const [6] IV (0x8167cdc) 1 PADOP (0x8193748) gvsv GV (0x816887c) \| BINOP (0x8189228) sassign COP (0x824c460) nextstate OP (0x824ffa8) pushmark SVOP (0x81892b8) const [7] PV (0x8168804) "first=" PADOP (0x818c5c0) gvsv GV (0x816887c) \| SVOP (0x818dc50) const [8] PV (0x8168810) " second=" PADOP (0x824fdb8) gvsv GV (0x816887c) *\| UNOP (0x824fc80) postinc [4] SVOP (0x824dc58) const [9] PV (0x81688a0) "\n" LISTOP (0x824ff80) print LISTOP (0x824d8e0) leave [1] [download] int the perl. Sorry, I was mistaken by the way one "programs" Perl in C via its interfaces. Thanks to all people who helped clearing this up. I will eventually make an addendum to my first post. Regards mwa	[reply] [d/l] [select]
Re^4: Puzzling $\| behavior by oha (Friar) on Oct 08, 2007 at 12:34 UTC
i think it's matter of the compiler optimizer: if i have something like f($x+=2, $x+=3); (and comma between arguments is not a sync point, like in C) then the optimizer could collapse $x+=2 and $x+=3 to $x+=5. It's not only matter of order. $_ = 1; f($_+=2, $_+=3); sub f { print shift, ", ", shift, "\n"; } print `perl -v`; __________ 6, 6 This is perl, v5.6.0 built for darwin .... [download] Oha	[reply] [d/l]
Re^5: Puzzling $\| behavior by ikegami (Patriarch) on Oct 08, 2007 at 16:58 UTC


Think about Loose Coupling
	PerlMonks