[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.
+
+=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
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 C > +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 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 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 > + > +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 I rather than "regular
@@ -612,6 +612,24 @@
All string values pay attention to the current C<:ignorecase> setting,
while C 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. --
