[OT] Re: [svn:perl6-synopsis] r13540 - doc/trunk/design/syn
Nicholas Clark writes: 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. It is undefined in C. The standard says that between any adjacent pair of sequence points, an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. Cb + ++b modifies b once, reads it once to determine the value to be stored (C++b), and also reads it one further time (to determine the result of the addition), so it's undefined. -- Aaron Crane
[svn:perl6-synopsis] r13540 - doc/trunk/design/syn
Author: larry
Date: Sat Jan 27 00:59:58 2007
New Revision: 13540
Modified:
doc/trunk/design/syn/S03.pod
Log:
Major reorganization of S03.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Jan 27 00:59:58 2007
@@ -2,7 +2,7 @@
=head1 TITLE
-Synopsis 3: Summary of Perl 6 Operators
+Synopsis 3: Perl 6 Operators
=head1 AUTHOR
@@ -12,30 +12,1292 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 22 Jan 2007
+ Last Modified: 26 Jan 2007
Number: 3
- Version: 90
+ Version: 91
+
+=head1 Overview
+
+For a summary of the changes from Perl 5, see L/Changes to Perl 5 operators.
+
+=head1 Operator precedence
+
+Not counting terms and terminators, Perl 6 has 20 operator precedence
+levels. (Perl 5 has 23!) Here we list the levels from tightest to
+loosest, along with a few examples of each level:
+
+Level Examples
+=
+Terms 42 3.14 eek qq[foo] $x :!verbose
+Method postfix .meth .+ .? .* .() .[] .{} . .«» .:: .= .^
+Autoincrement ++ --
+Exponentiation **
+Symbolic unary ! + - ~ ? $ @ % | +^ ~^ ?^ \ ^ =
+Multiplicative * / % x xx + + + ~ ~ ~ ? div mod
+Additive+ - ~ +| +^ ~| ~^ ?| ?^
+Junctive and (all)
+Junctive or (any) | ^
+Named unary rand sleep abs -e -r -w -x
+Nonchaining binary but does = leg cmp .. ..^ ^.. ^..^ ff fff
+Chaining binary != == = = eq ne lt le gt ge ~~ === eqv !eqv
+Tight and
+Tight or|| ^^ // min max
+Conditional ?? !!
+Item assignment = := ::= = += -= **= xx= .=
+Loose unary true not
+List ops, = print push say die map substr ... [+] [*] any all
+List infix ¥ == == minmax X XX X~X X*X XeqvX
+Loose and and
+Loose oror xor err
+Terminator ; {...}, modifiers, unmatched ), ], }
+
+If you don't see your favorite operator there, the following
+sections cover all the operators in precedence order. Basic operator
+descriptions are here; special topics are covered afterwards.
+
+=head2 Term precedence
+
+This isn't really a precedence level, but it's in here because no operator
+can have tighter precedence than a term. See S02 for longer descriptions of
+various terms.
+
+=over
+
+=item *
+
+Int literal
+
+42
+
+=item *
+
+Num literal
+
+3.14
+
+=item *
+
+Non-interpolating Str literal
+
+'$100'
+
+=item *
+
+Interpolating Str literal
+
+Answer = $answer\n
+
+=item *
+
+Generalized Str literal
+
+q[$100]
+qq[$answer]
+
+=item *
+
+Array composer
+
+[1,2,3]
+
+=item *
+
+Hash composer
+
+{ a = 42 }
+
+=item *
+
+Closure
+
+{...}
+
+=item *
+
+Capture composer
+
+\(@a,$b,%c)
+
+=item *
+
+Sigiled variables
+
+$x
+@y
+%z
+$^a
+$?FILE
+@@multidim
+func
+div:(Int, Int -- Int)
+
+=item *
+
+Sigils as contextualizer functions
+
+$()
+@()
+%()
+()
+@@()
+
+=item *
+
+Regexes in quote-like notation
+
+/abc/
+rx:i[abc]
+s/foo/bar/
+
+=item *
+
+Transliterations
+
+tr/a..z/A..Z/;
+
+Note ranges use C.. rather than C-.
+
+=item *
+
+Type names
+
+Num
+::Some::Package
+
+=item *
+
+Circumfixed subexpressions
+
+(1+2)
+
+Circumfixed items are treated like a term on the outside.
+
+=item *
+
+Function call
+
+a(1)
+
+=item *
+
+Pair composers
+
+:by(2)
+:!verbose
+
+=item *
+
+Signature literal
+
+:(Dog $self:)
+
+=item *
+
+Method call with implicit invocant
+
+.meth # call on $_
+.=meth # modify $_
+
+=item *
+
+Listop (leftward)
+
+4,3, sort 2,1 # 4,3,1,2
+
+As in Perl 5, a list operator looks like a term to the expression on
+its left, so it binds tighter than comma on the left but looser than
+comma on the right--see List operator precedence below.
+
+=back
+
+=head2 Method postfix precedence
+
+All method postfixes start with a dot, though the dot is optional
+for subscripts. Since these are the tightest standard operator,
+you can often think of a series of method calls as a single term that
+merely expresses a complicated name.
+
+See S12 for more discussion of single dispatch method calls.
+
+=over
+
+=item *
+
+Standard single-dispatch method calls
+
+$obj.meth
+
+=item *
+
+Variants of standard single-dispatch method call
+
+$obj.+meth
+$obj.?meth
+$obj.*meth
+
+In addition to the ordinary C. method invocation, there are variants
+C.*, C.?, and C.+ to control how multiple related methods of
+the same name are handled.
+
+=item *
+
+Class-qualified method call
+
+$obj.::Class::meth
+
+=item *
+
+Mutating method call
+
+$obj.=meth
+
+The C.= operator does inplace modification of the object on the left.
+
Re: [svn:perl6-synopsis] r13540 - doc/trunk/design/syn
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 CInt**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 Cerr 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 CPair 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
Re: [svn:perl6-synopsis] r13540 - doc/trunk/design/syn
On Sat, Jan 27, 2007 at 06:18:50PM +, Nicholas Clark wrote: 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 :-) In C, that is deliberately left undefined to allow the code generator to have more flexibility in optimizing the code it generates. It's always easy to separate side-effects into multiple statements that are executed in the desired order if you need a specific order. If everything in the language implies a specific order, no opportunity for optimization remains - even if there is no actual necessity for the particular order to be followed. --
