[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: Remember: Outlaw to declare a lexical twice in the same scope
Steve Lukas (): Hi @larry, I want to remember to my proposal from september 2006. It targets on changing S04. The discussion is summarized on: http://www.oreillynet.com/onlamp/blog/2006/09/weekly_perl_6_mailing_list_sum_3.html So, please change S04 as discussed. I, too, would like to point to this as an important issue. It would be nice if someone could point to a good reason to change this behavior from the one in Perl 5. I might be all wrong in my reasons to be horrified at the following: my $foo; # ...later in the same scope... my $foo; # illegal Perl5, legal Perl6 But if I am, I would like to know why. Perl6 is strict in not letting the programmer declare a variable less then once, why shouldn't it be strict in not letting them declare it more than once? -- masak
Re: Remember: Outlaw to declare a lexical twice in the same scope
On Sat, Jan 27, 2007 at 10:23:03AM +0100, Carl Mäsak wrote:
my $foo;
# ...later in the same scope...
my $foo; # illegal Perl5, legal Perl6
No, that's perfectly legal in perl5; it just generates a warning:
use warnings;
my $x = 1;
my $f1 = sub { $x };
my $x = 2;
my $f2 = sub { $x };
printf f1=%d f2=%d x=%d\n, $f1-(), $f2-(), $x;
which gives
$ perl588 /tmp/p
my variable $x masks earlier declaration in same scope at /tmp/p line 6.
f1=1 f2=2 x=2
--
But Pity stayed his hand. It's a pity I've run out of bullets,
he thought. -- Bored of the Rings
Re: Remember: Outlaw to declare a lexical twice in the same scope
Dave (), Carl ():
my $foo;
# ...later in the same scope...
my $foo; # illegal Perl5, legal Perl6
No, that's perfectly legal in perl5; it just generates a warning:
use warnings;
my $x = 1;
my $f1 = sub { $x };
my $x = 2;
my $f2 = sub { $x };
printf f1=%d f2=%d x=%d\n, $f1-(), $f2-(), $x;
which gives
$ perl588 /tmp/p
my variable $x masks earlier declaration in same scope at /tmp/p line 6.
f1=1 f2=2 x=2
Ah, your quite right. Going back, I see that this was indeed pointed
out in the original thread as well; I just didn't catch it then.
http://groups.google.com/group/perl.perl6.language/browse_frm/thread/05c902b290fb7a5a/f9506f5acde3ceb4?#f9506f5acde3ceb4
FWIW, I think a warning is fine. (Because in my world a warning means
that something isn't perfectly legal.) Maybe it's in line with
Perl's policy of being forgiving when possible to give a warning
instead of a compile-time error. That's fine.
What bothers me is that one might not even get a warning in Perl 6.
Since a duplicated variable declaration is often due to programmer
confusion, it seems like we're passing up such a fine opportunity for
telling them about it. What underlying design decision is it that
prevents us from giving a warning here, as in Perl 5?
Pugs currently executes the above code and gives the same output, but
no warning:
$ pugs test.pl
f1=2 f2=2 x=2
// Carl
Re: Remember: Outlaw to declare a lexical twice in the same scope
Carl Mäsak writes: my $foo; # ...later in the same scope... my $foo; # illegal Perl5, legal Perl6 That isn't illegal in Perl 5. It yields the warning: my variable $foo masks earlier declaration in same scope but it does work. Smylers
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
[svn:perl6-synopsis] r13541 - doc/trunk/design/syn
Author: larry
Date: Sat Jan 27 13:27:55 2007
New Revision: 13541
Modified:
doc/trunk/design/syn/S05.pod
Log:
Note that @ish quoting forms can save wear and tear on the ' ' keys.
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podSat Jan 27 13:27:55 2007
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud [EMAIL PROTECTED] and
Larry Wall [EMAIL PROTECTED]
Date: 24 Jun 2002
- Last Modified: 19 Jan 2007
+ Last Modified: 27 Jan 2007
Number: 5
- Version: 46
+ Version: 47
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them Iregex rather than regular
@@ -612,6 +612,24 @@
All string values pay attention to the current C:ignorecase setting,
while CRegex values use their own C:ignorecase settings.
+When you get tired of writing:
+
+token sigil { '$' | '@' | '@@' | '%' | '' | '::' }
+
+you can write:
+
+token sigil { @('$','@','@@','%','','::') }
+
+or
+
+token sigil { @( $ @ @@ % :: ) }
+
+or (conjecturally) maybe just:
+
+token sigil { @: $ @ @@ % :: }
+
+assuming we make the C@: contextualizer govern only the next token.
+
=item *
An interpolated hash matches the longest possible key of the hash
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. --
