It has been published at perl6.language, but have no reply.

In perl v5.8.6 built for MSWin32-x86-multi-thread:

my $i = 1;
print $i++, ++$i; # 1 3
my $i = 1;
print ++$i, $i++; # 3 2

in pugs:

my $i = 1;
say $i++, ++$i; # 1 3

my $i = 1;
say ++$i, $i++; # 2 2

which is right?(I think perl5 is) or it's different between Perl5 and Perl6?

thanks.

/Fayland Lam/
--------------
http://www.fayland.org

I think I understand the implementation details leading to each
behaviour, but rather than saying which was "right", I think I'd be
quite happy to see Perl6 copy (the ideas behind) C's rules regarding
sequence points and undefined behaviour.  I'm not so sure about
implementation defined and unspecified behaviour.

When I see code such as this, I usually encourage people to program Perl
as if it had sequence points and undefined behaviour.  This often
results in explaining what they are, but maybe that's not such a great
problem.

See http://www.eskimo.com/~scs/C-faq/faq.html, especially sections 3.8
and 11.33 for details.

--
Paul Johnson - p...@pjcj.net
http://www.pjcj.net

Isn't this the old prefix-++ problem:

  @a = (++$i,++$i,++$i);
  print "@a";    # prints 3 3 3

-- Johan

It certainly makes more sense to me that the answer would be 2 2.  But
however it ends up, so long as we know what the answer will be, we can
utilize it effectively in our programs.

-kolibrie

The trick with this construct usually in C is that the C standard doesn't
specify the order of evaluation of function arguments, so you can never be
sure if you'll get the same result if you compile it other than on your
development system (different compilers may evaluate them in a different
order). The Pugs example given in the original post seems to me to be
fairly sane, as it shows left-to-right evaluation. The Perl 5 example, as
far as I can tell, shows left-to-right for the first case and
right-to-left for the second case, which is just odd... please correct me
if I'm wrong, but that seems the only way those answers could have been
arrived at.
So really, what needs to be said is how Perl 6 is supposed to evaluate the
arguments to function calls, then we can know if the current behaviour in
Pugs is correct.

That "trick" in the C language is not an accident, but
deliberate.  Leaving the result undefined allows compiler
writers to choose the definition that fits best for that
compiler's internal structure and/or the target hardware
architechture.  Thus, when people write code that doesn't
happen to care about the abiguity in the spec, it is processed
(run/compiled) in the best way the compiler writer can provide.

In C, at least, you can't always tell whether a particular
statement is ambiguous (e.g. "i = *p1++ + *p2++" - do p1 and p2
always point to different memory locations?) and the cost of
treating it in an ambiguity-safe manner might be significant,
since C tends to get used for low level critical operations.

The approach is: make the programmer handle the rare tough cases
himself and let the compiler do the common job really well.
That is similar to "easy things should be easy, hard things
should be possible" but C puts more emphasis on run time speed
than programmer utility in how it applies its philosophy.

--

On 21 Apr, fayland wrote:

: It has been published at perl6.language, but have no reply.

That was to be expected, as it's no language-design specific issue,
and therefore, unsuitable for p6l.

: In perl v5.8.6 built for MSWin32-x86-multi-thread:
:
: my $i = 1;
: print $i++, ++$i; # 1 3
: my $i = 1;
: print ++$i, $i++; # 3 2

You're misleaded here, by thinking, scalar context is being enforced,
which is not the case; the results of the increment operator operations (ops)
on the scalar are being passed in (implicit) array context to the print builtin.

Every Perl program, that gets compiled and interpreted, will be
converted to a syntax tree initially. The following is a selected excerpt
from the output of the core module B::Terse, which displays, what syntax
tree we actually got hold of.

    LISTOP (0x3c013760) print
        OP (0x3c013780) pushmark
        UNOP (0x3c013700) postinc [2]
            OP (0x3c0136e0) padsv [1]
        UNOP (0x3c013740) preinc
            OP (0x3c013720) padsv [1]

So, LISTOP indicates, that a list context is being encountered, which is
not, what we actually want. The syntax trees for the two examples,
provided above, don't differ that much, except, as you'd assume, in case
of the ordering of the UNOPs. I don't see any way to explain, what's
going wrong *exactly* by examining the syntax tree; that'd require
digging into the internals, I'd assume.

        my $i = 1;

and either

        print $i++; print ++$i;
or
        print ++$i; print $i++;

does what you assumed, it was supposed to do, but without
having the compiler struggling against implicit assumptions.

: in pugs:
:
: my $i = 1;
: say $i++, ++$i; # 1 3
:
: my $i = 1;
: say ++$i, $i++; # 2 2

This leads me to think, Pugs has implemented the behaviour, that has
been outlayed in Apocalypse 03: Operators, RFC 082 - Arrays: Apply
operators element-wise in a list context,
http://dev.perl.org/perl6/doc/design/apo/A03.html

: which is right?(I think perl5 is) or it's different between Perl5 and
Perl6?

I'm not inclined to think, that Perl 5 is wrong here, as letting it
assume array context, is in this context, like assuming, filling your
fridge with food, it consists of, by randomly throwing some of it in,
will come out sorted again; Perl 6 does, what the specifications urge
upon it to do.

: /Fayland Lam/

Steven