Author: larry
Date: Thu Feb 22 12:51:15 2007
New Revision: 13700

Modified:
   doc/trunk/design/syn/S02.pod
   doc/trunk/design/syn/S03.pod
   doc/trunk/design/syn/S06.pod

Log:
More Y XX -> Z X clarifications
Now allow "constant $?TABSTOP = 4" syntax for user to set compiler variables.


Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod        (original)
+++ doc/trunk/design/syn/S02.pod        Thu Feb 22 12:51:15 2007
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 10 Aug 2004
-  Last Modified: 15 Feb 2007
+  Last Modified: 22 Feb 2007
   Number: 2
-  Version: 88
+  Version: 89
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -1567,12 +1567,25 @@
 in fact be dynamically scoped within the compiler itself, and only
 appear to be lexically scoped because dynamic scopes of the compiler
 resolve to lexical scopes of the program.  All C<$?> variables are considered
-constants, and may not be modified after being compiled in.
+constants, and may not be modified after being compiled in.  The user
+is also allowed to define or (redefine) such constants:
+
+    constant $?TABSTOP = 4;     # assume heredoc tabs mean 4 spaces
+
+(Note that the constant declarator always evaluates its initialization
+expression at compile time.)
 
 C<$?FILE> and C<$?LINE> are your current file and line number, for
 instance.  C<?> is not a shortcut for a package name like C<*> is.
-Instead of C<$?OUTER::SUB> you probably want to write C<< OUTER::<$?SUB>
->>.
+Instead of C<$?OUTER::SUB> you probably want to write C<< OUTER::<$?SUB> >>.
+Within code that is being run during the compile, such as BEGIN blocks,
+or macro bodies, or constant initializers, the compiler variables must
+be referred to as C<< COMPILING<$?LINE> >> if the bare C<$?LINE> would
+be taken to be the value during the compilation of the currently running
+code rather than the eventual code of the user's compilation unit.  For
+instance, within a macro body C<$?LINE> is the line within the macro
+body, but C<< COMPILING::<$?LINE> >> is the line where the macro was invoked.
+See below for more about the C<COMPILING> pseudo package.
 
 Here are some possibilities:
 

Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod        (original)
+++ doc/trunk/design/syn/S03.pod        Thu Feb 22 12:51:15 2007
@@ -1107,6 +1107,13 @@
 
     ('a', '1'), ('a', '2'), ('b', '1'), ('b', '2')
 
+This becomes a flat list in C<@> context and a list of arrays in C<@@> context:
+
+    say @(<a b> X <1 2>)
+    'a', '1', 'a', '2', 'b', '1', 'b', '2'
+    say @@(<a b> X <1 2>)
+    ['a', '1'], ['a', '2'], ['b', '1'], ['b', '2']
+
 =item *
 
 Cross hyperoperators

Modified: doc/trunk/design/syn/S06.pod
==============================================================================
--- doc/trunk/design/syn/S06.pod        (original)
+++ doc/trunk/design/syn/S06.pod        Thu Feb 22 12:51:15 2007
@@ -1518,7 +1518,7 @@
     right       ** =            $a op ($b op $c)                **
     non         cmp <=> ..      ILLEGAL                         cmp
     chain       == eq ~~        ($a op $b) and ($b op $c)       eqv
-    list        | & ^ ¥         op($a, $b, $c)                  |
+    list        | & ^ Z         op($a; $b; $c)                  |
 
 Note that operators "C<equiv>" to relationals are automatically considered
 chaining operators.  When creating a new precedence level, the chaining

Reply via email to