Re: [svn:perl6-synopsis] r9727 - doc/trunk/design/syn
On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +In particular, these forms disable the lookahead for an adverbial argument, +so while + +q:n($foo) + +will misinterpret C$foo as the C:n argument, + +qn(stuff) + +has the advantage of misinterpreting it as the argument to the Cqn() +function instead. C:) + +But parens are special that way. Other bracketing characters are special +only if they can be mistaken for adverbial arguments, so + +qn[stuff] + +is fine, while + +q:n[stuff] + +is not. Basically, just don't use parens for quote delimiters, and always +put a space after your adverbs. Why q:n[stuff] is not fine? Shouldn't that pass [stuff] to adverb n? Also, in what way are parens special? Doesn't qn(stuff) and qn[stuff] both mean same thing? And both q:n(stuff) and q:n[stuff] pass something to adverb n. (First passes stuff, second passes [stuff]) -- Markus Laire
[svn:perl6-synopsis] r9731 - doc/trunk/design/syn
Author: larry
Date: Sat Jul 1 12:13:49 2006
New Revision: 9731
Modified:
doc/trunk/design/syn/S03.pod
Log:
Revisions from Bruce Gray++.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Jul 1 12:13:49 2006
@@ -12,14 +12,17 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 30 Jun 2006
+ Last Modified: 1 Jul 2006
Number: 3
- Version: 43
+ Version: 44
=head1 Changes to existing operators
Several operators have been given new names to increase clarity and better
-Huffman-code the language, while others have changed precedence.
+Huffman-code the language, while others have changed precedence. (If an
+operator is not mentioned in this Synopsis, assume that it remains the
+same as in Perl 5. And if that doesn't make sense, assume this document
+is faulty. :)
=over
@@ -379,14 +382,16 @@
so C^Moose is short for CMoose.meta. It still kinda means what
is this thing's domain in an abstract sort of way.
-=item * The C... prefix operator is the
-yada, yada, yada operator, which is used as the body in function
-prototypes. It complains bitterly (by calling Cfail) if it is
-ever executed. Variant C??? calls Cwarn, and C!!! calls Cdie.
-The argument is optional, but if provided, is passed onto the Cwarn,
-Cfail, or Cdie. Otherwise the system will make up a message for
-you based on the context. We can't be responsible for what it might
-say.
+=item * The C... operator is the yada, yada, yada list operator,
+which is used as the body in function prototypes. It complains
+bitterly (by calling Cfail) if it is ever executed. Variant C???
+calls Cwarn, and C!!! calls Cdie. The argument is optional,
+but if provided, is passed onto the Cfail, Cwarn, or Cdie.
+Otherwise the system will make up a message for you based on the
+context, indicating that you tried to execute something that is
+stubbed out. (This message differs from what Cfail, Cwarn, and
+Cdie would say by default, since the latter operators typically point
+out bad data or programming rather than just an incomplete design.)
=item * In addition to the ordinary C. method invocation, there are
variants C.*, C.?, and C.+ to control how multiple related methods
@@ -809,9 +814,9 @@
=head1 Junctive operators
-C|, C, and C^ are no longer bitwise operators (see L/Operator
-Renaming) but now serve a much higher cause: they are now the
-junction constructors.
+C|, C, and C^ are no longer bitwise operators (see
+L/Changes to existing operators) but now serve a much higher cause:
+they are now the junction constructors.
A junction is a single value that is equivalent to multiple values. They
thread through operations, returning another junction representing the
@@ -892,8 +897,9 @@
state $foo # persistent lexical (cloned with closures)
constant $foo # lexically scoped compile-time constant
-Variable declarators such as Cmy now take a CSignature as their
-argument. The parentheses around the signature may be omitted for a
+Variable declarators such as Cmy now take a Isignature as their
+argument. (The syntax of function signatures is described more fully in S06.)
+The parentheses around the signature may be omitted for a
simple declaration that declares a single variable, along with its
associated type and traits. Parentheses must always be used when
declaring multiple parameters:
@@ -902,17 +908,30 @@
my ($b, $c); # okay
my $b, $c; # wrong: Use of undeclared variable: $c
-The syntax for a CSignature when one isn't expected is:
+[XXX the following probably belongs in S06.]
+The syntax for constructing a CSignature object when the parser isn't already
+expecting one is:
:(Dog $a, [EMAIL PROTECTED])
-The colon (and sometimes the parens) may be omitted within declarators
-where a signature is expected, for instance in the formal list of a loop
-block:
+This might be used like this:
+
+my $sig = :(Dog $a, [EMAIL PROTECTED]);
+
+Signatures are expected after declarators such as Cmy, Csub, Cmethod,
+Crule, etc. In such declarators the colon may be omitted. But it's
+also legal to use it:
+
+my :($b, $c); # okay
+sub foo :($a,$b) {...} # okay
+
+The C - pointy sub token also introduces a signature, but
+in this case you must omit both the colon and the parens. For instance,
+if you're defining the loop variable of a loop block:
for @dogpound - Dog $fido { ... }
-If a CSignature is assigned to (whether declared or colon form), the
+If a signature is assigned to (whether declared or colon form), the
signature is converted to a list of lvalue variables and the ordinary
rules of assignment apply, except that the evaluation of the right
side and the assignment happens at time determined by the declarator.
@@ -924,10 +943,10 @@
[svn:perl6-synopsis] r9732 - doc/trunk/design/syn
Author: larry Date: Sat Jul 1 12:20:14 2006 New Revision: 9732 Modified: doc/trunk/design/syn/S05.pod Log: Deconfusing match state and state vars from Bruce Gray++. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podSat Jul 1 12:20:14 2006 @@ -14,18 +14,18 @@ Maintainer: Patrick Michaud [EMAIL PROTECTED] and Larry Wall [EMAIL PROTECTED] Date: 24 Jun 2002 - Last Modified: 30 June 2006 + Last Modified: 1 July 2006 Number: 5 - Version: 27 + Version: 28 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them Iregex because they haven't been regular expressions for a long time. When referring to their use in a grammar, the term Irule is preferred. -=head1 New match state and capture variables +=head1 New match result and capture variables -The underlying match state object is now available as the C$/ +The underlying match result object is now available as the C$/ variable, which is implicitly lexically scoped. All access to the current (or most recent) match is through this variable, even when it doesn't look like it. The individual capture variables (such as C$0,
Re: [svn:perl6-synopsis] r9727 - doc/trunk/design/syn
On Sat, Jul 01, 2006 at 03:31:52PM +0300, Markus Laire wrote: : On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: : +In particular, these forms disable the lookahead for an adverbial : argument, : +so while : + : +q:n($foo) : + : +will misinterpret C$foo as the C:n argument, : + : +qn(stuff) : + : +has the advantage of misinterpreting it as the argument to the Cqn() : +function instead. C:) : + : +But parens are special that way. Other bracketing characters are special : +only if they can be mistaken for adverbial arguments, so : + : +qn[stuff] : + : +is fine, while : + : +q:n[stuff] : + : +is not. Basically, just don't use parens for quote delimiters, and always : +put a space after your adverbs. : : Why q:n[stuff] is not fine? Shouldn't that pass [stuff] to adverb n? That's what it does. But it's not fine if you expected [...] to delimit the quoted string instead. : Also, in what way are parens special? : Doesn't qn(stuff) and qn[stuff] both mean same thing? Nope, qn(stuff) is always a function call. q(foo) is always a function call, not a quote. : And both q:n(stuff) and q:n[stuff] pass something to adverb n. (First : passes stuff, second passes [stuff]) That is correct. My intent with the quote declarator however is that there be an implicit space after it, so the n on the end of qn no longer functions as an adverb, at least in terms of looking for a subsequent argument. I will attempt to clarify the distinction between quotes and ordinary macros. Thanks. Larry
[svn:perl6-synopsis] r9733 - doc/trunk/design/syn
Author: larry
Date: Sat Jul 1 13:55:09 2006
New Revision: 9733
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S06.pod
Log:
Clarification of differences between quote and macro declarations, Markus++.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podSat Jul 1 13:55:09 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 10 Aug 2004
- Last Modified: 30 Jun 2006
+ Last Modified: 1 July 2006
Number: 2
- Version: 47
+ Version: 48
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -1361,8 +1361,8 @@
quote qTO = 'qq:x:w:to';# qq:x:w:to//
quote circumfix:❰ ❱ = q:code { .quoteharder }; # or some such...
-In particular, these forms disable the lookahead for an adverbial argument,
-so while
+In particular, all these forms disable the lookahead for an adverbial argument,
+as if there were a space after the keyword. So although
q:n($foo)
@@ -1373,23 +1373,42 @@
has the advantage of misinterpreting it as the argument to the Cqn()
function instead. C:)
-But parens are special that way. Other bracketing characters are special
-only if they can be mistaken for adverbial arguments, so
+But parens are special that way. (Even Cq() is assumed to be a
+function call rather than a quote.) Other bracketing characters are
+special only if they can be mistaken for adverbial arguments, so
qn[stuff]
-is fine, while
+is fine, and means
+
+q:n /stuff/
+
+while
q:n[stuff]
-is not. Basically, just don't use parens for quote delimiters, and always
-put a space after your adverbs.
+is not so fine, if the user intended stuff to be the string rather
+than an argument to C:n. Basically, you'll be fine if you just
+never use parens for quote delimiters, and always put a space after
+your adverbs.
If this is all too much of a hardship, you can define your own quote
-adverbs and operators as standard macros.
-All the uppercase adverbs are reserved for
-user-defined quotes. All of Unicode above Latin-1 is reserved for
-user-defined quotes.
+adverbs and operators as standard macros. The main difference is that,
+unlike
+
+quote qn = 'q:n';
+
+declaring something like
+
+macro qn { 'q:n' }
+
+does Inot disable the subsequent search for an argument to C:n. To
+get the equivalent, you need to add a space:
+
+macro qn { 'q:n ' }
+
+All the uppercase adverbs are reserved for user-defined quotes.
+All Unicode delimiters above Latin-1 are reserved for user-defined quotes.
=item *
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSat Jul 1 13:55:09 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 21 Mar 2003
- Last Modified: 30 June 2006
+ Last Modified: 1 July 2006
Number: 6
- Version: 38
+ Version: 39
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -2156,10 +2156,13 @@
the user. Syntax trees are also better in general because they are
reversible, so things like syntax highlighters can get back to the
original language and know which parts of the derived program come
-from which parts of the user's view of the program.
+from which parts of the user's view of the program. Nevertheless,
+it's difficult to return a syntax tree for an unbalanced construct,
+and in such cases a textual macro may be a clearer expression of the
+evil thing you're trying to do.
If you call a macro at runtime, the result of the macro is automatically
-evaluated again, so the two calls below prints the same thing:
+evaluated again, so the two calls below print the same thing:
macro f { '1 + 1' }
say f();# compile-time call to f
@@ -2261,7 +2264,9 @@
else.) Of course, the macro definition as a whole can expect
whatever it likes afterwards, according to its syntactic category.
(Generally, a term expects a following postfix or infix operator,
-and an operator expects a following term or prefix operator.)
+and an operator expects a following term or prefix operator. This
+does not matter for textual macros, however, since the reparse of
+the text determines subsequent expectations.)
Quasiquotes default to hygienic lexical scoping, just like closures.
The visibility of lexical variables is limited to the q:code expression
S04
I picked this up at the YAPC and made some markups on it. Apologies that it is not in a diff format, but that's going to come with practice. I got stuck on some of the intended behaviors and prohibited behaviors of the 'goto' function. For the purpose of clarity would it be useful to provide a series of specific test cases (in perl 5) to identify what it does today and what (if anything) it will do differently? Thank you, Tom Allison
