On Sat, Jan 27, 2007 at 12:59:59AM -0800, [EMAIL PROTECTED] wrote:
> +As in C, these operators increment or decrement the object in question
> +either before or after the value is taken from the object, depending on
> +whether it is put before or after. Also as in C, use of multiple side
> +effects on a single object in the same expression results in undefined
> +behavior unless some explicit sequencing operator is interposed.
Nothing in the repository yet defines what is a sequencing operator.
Also, I'm never totally confident on what isn't quite undefined behaviour in
C, but something like
$a = $b + ++$b;
doesn't appear to have multiple side effects, yet it ought to be undefined.
(Unless "reading a value you also modified" counts as a side effect)
> +infix:<**> exponentiation operator
> +
> + $x ** 2
> +
> +If the right argument is not an integer, the result is likely to
> +be an approximation. If the right argument is of an integer type,
> +exponentiation is at least as accurate as repeated multiplication on
> +the left side's type. (From which it can be deduced that C<Int**Int>
> +is always exact, since Int supports arbitrary precision.) If the
I believe that that should start with "positive integer type"
3 ** -1
is unlikely to be accurate.
> +For instance, C<=$iterator> is scalar/list sensitive and will
should that be item/list?
> +infix:<//>, defined-or
> +
> + //
> +
> +Returns the left argument if it's defined, otherwise the right argument.
> +In list context forces a false return to mean C<()>.
> +See C<err> below for low-precedence version.
Is this short-circuiting?
> +=head2 Conditional precedence
> +
> +=over
> +
> +=item *
> +
> +?? !!
> +
> + say "My answer is: ", $maybe ?? "yes" !! "no";
> +
> +It is a syntax error to use an
> +operator in the middle that binds looser in precedence, such as C<=>.
This doesn't make it explicit that only one of "yes" or "no" is evaluated.
Then again, neither does the Perl 5 documentation.
> +Binary C<< => >> is no longer just a "fancy comma". It now constructs
> +a C<Pair> object that can, among other things, be used to pass named
> +arguments to functions. It provides scalar context to both sides.
Should that be "item" ?
> +The minmax operator
> +
> + $min0, $max0 minmax $min1, $max1 # ($min0 min $min1, $max0 max $max1)
This explanation doesn't make sense to me. Should I drink more coffee?
> +infix:<and>
> +
> + and
> +
> +Returns the left argument if the left argument is false, otherwise returns
> +the right argument. In list context forces a false return to mean C<()>.
> +See C<&&> above for high-precedence version.
As these are short circuiting, would it be better to say
"otherwise evaluates and returns the right argument"
(likewise for or and err)
Is it defined that $a + $b evaluates the arguments in any particular order?
Even guaranteeing that either the left or the right gets completely evaluated
first would be better than C :-)
Nicholas Clark
