123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107 |
- I wonder if this strange behaviour is known:
- $ perl -e'my $i = 1;
- my $foo = sub {
- $i = shift if @_
- };
- print $i,&$foo(3),$i;'
- 333
- $ perl -e'my $i = 1;
- my $foo = sub {
- $i = shift if @_
- };
- print $i; print &$foo(3),$i;'
- 133
- The first seems very wrong to me. The 2nd arg $foo, a cv - even a
- closure, but this is not relevant in general - must not be evaluated
- before the 1st arg of print.
- There's something wrong with the argument handling in the compiler
- and/or run-time, affecting side-effects only - such as the evaluation
- here. I'll scratching my head now how to fix this, if wanted. IMO it
- should be fixed. To which ops this really should be compiled to, if
- it can be detected on the compiler level. e.g. "not-special ops" with
- list args with cv's, which are not the 1st arg. Such as our print
- here. Or if it needs a fix in some of the LISTOP pp_ functions, like
- pp_print().
- http://groups.google.com/group/perl.perl6.language/tree/browse_frm/thread/508f65ac12195a59/0f35e622211975bd?rnum=61&_done=%2Fgroup%2Fperl.perl6.language%2Fbrowse_frm%2Fthread%2F508f65ac12195a59%3F#doc_617344f05578681a
- Rafael once wrote:
- The implicit assumption is that C<,> guarantees
- evaluation order. Like the comma operator in C IIRC.
- -- This would be nice, but is wrong.
- Mark Overmeer then wrote:
- In the C language, the comma does not define the order of evaluation,
- which is cause of many conversion problems.
- -- Well, in lisp special arrangements are made for faster register passing -
- a bogus argument, but I heard it for parrot - and possible parallel evaluation,
- so left-to-right in special functions is not always guaranteed -- Reini
- In Perl, the comma is strictly evaluated from left to right in scalar context (explicitly
- described perlop).
- In LIST context, the comma is not an operator at all, but an expression
- separator like ';' And therefore, the comma is not in for re-ordering
- in an argument list.
- -- Now this is true, but only half of the truth.
- And I know that Larry wrote, that perl5 is mistaken here, and perl6 should get
- it right. This was in 2003.
- But since it's quite easy to fix, it should be fixed in perl5, as everyone
- expects such args to be evaluated left-to-right.
- http://groups.google.com/groups?selm=bhok6j%2470f%241%40plover.com
- first, wrong:
- 1 <0> enter
- 2 <;> nextstate(main 1 -e:1) v:{
- 3 <$> const[IV 1] s
- 4 <0> padsv[$i:1,4] sRM*/LVINTRO
- 5 <2> sassign vKS/2
- 6 <;> nextstate(main 3 -e:4) v:{
- 7 <0> pushmark sRM
- 8 <$> anoncode[CV ] lRM
- 9 <1> refgen sK/1
- a <0> padsv[$foo:3,4] sRM*/LVINTRO
- b <2> sassign vKS/2
- c <;> nextstate(main 4 -e:5) v:{
- d <0> pushmark s
- e <0> padsv[$i:1,4] l
- f <0> pushmark s
- g <$> const[IV 3] sM
- h <0> padsv[$foo:3,4] s
- i <1> entersub[t4] lKS/TARG,1
- j <0> padsv[$i:1,4] l
- k <@> print vK
- l <@> leave[1 ref] vKP/REFC
- second ok:
- 1 <0> enter
- 2 <;> nextstate(main 1 -e:1) v:{
- 3 <$> const[IV 1] s
- 4 <0> padsv[$i:1,4] sRM*/LVINTRO
- 5 <2> sassign vKS/2
- 6 <;> nextstate(main 3 -e:4) v:{
- 7 <0> pushmark sRM
- 8 <$> anoncode[CV ] lRM
- 9 <1> refgen sK/1
- a <0> padsv[$foo:3,4] sRM*/LVINTRO
- b <2> sassign vKS/2
- c <;> nextstate(main 4 -e:5) v:{
- d <0> pushmark s
- e <0> padsv[$i:1,4] l
- f <@> print vK
- g <;> nextstate(main 4 -e:5) v:{
- h <0> pushmark s
- i <0> pushmark s
- j <$> const[IV 3] sM
- k <0> padsv[$foo:3,4] s
- l <1> entersub[t4] lKS/TARG,1
- m <0> padsv[$i:1,4] l
- n <@> print vK
- o <@> leave[1 ref] vKP/REFC
|