[svn:perl6-synopsis] r9733 - doc/trunk/design/syn
la...@cvs.perl.org
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.pod Sat Jul 1 13:55:09 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <la...@wall.org>
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 C<qn()>
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 C<q()> 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 I<not> 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.pod Sat Jul 1 13:55:09 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <la...@wall.org>
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
Markus Laire
> +But parens are special that way. (Even C<q()> 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
Since quotes can have whitespace before the first/opening delimiter,
but functions can't (according to S03), how is C<q ()> parsed? (Notice
the space before parens).
Would that be parsed as invalid function-call (i.e. syntax error) or
valid quote?
--
Markus Laire
Larry Wall
It's a valid quote.
Larry