Revision 29004

Date:
2009/11/06 17:35:03
Author:
lwall
Revision Log:
[S04] Set phasers to stun!
Files:

Legend:

 
Added
 
Removed
 
Modified
  • docs/Perl6/Spec/S04-control.pod

     
    13 13
    14 14 Created: 19 Aug 2004
    15 15
    16 Last Modified: 10 Oct 2009
    17 Version: 84
    16 Last Modified: 06 Nov 2009
    17 Version: 85
    18 18
    19 19 This document summarizes Apocalypse 4, which covers the block and
    20 20 statement syntax of Perl.
     
    1117 1117 eventually decide to abort and print all unhandled exceptions found
    1118 1118 in the C<$!> that it is responsible for.
    1119 1119
    1120 =head1 Closure traits
    1120 =head1 Phasers
    1121 1121
    1122 A C<CATCH> block is just a trait of the closure containing it. Other
    1123 blocks can be installed as traits as well. These other blocks are
    1124 called at various times, and some of them respond to various control
    1125 exceptions and exit values:
    1122 A C<CATCH> block is just a trait of the closure containing it, and is
    1123 automatically called at the appropriate moment. These auto-called
    1124 blocks are known as I<phasers>, since they generally mark the
    1125 transition from one phase of computing to another. For instance,
    1126 a C<CHECK> block is called at the end of compiling a compilation
    1127 unit. Other kinds of phasers can be installed as well; these are
    1128 automatically called at various times as appropriate, and some of
    1129 them respond to various control exceptions and exit values:
    1126 1130
    1127 1131 BEGIN {...}* at compile time, ASAP, only ever runs once
    1128 1132 CHECK {...}* at compile time, ALAP, only ever runs once
     
    1169 1173 time may not persist under run-time cloning of any surrounding closure.)
    1170 1174
    1171 1175 Code that is generated at run time can still fire off C<CHECK>
    1172 and C<INIT> blocks, though of course those blocks can't do things that
    1173 would require travel back in time.
    1176 and C<INIT> phasers, though of course those phasers can't do things that
    1177 would require travel back in time. You need a wormhole for that.
    1174 1178
    1175 Some of these also have corresponding traits that can be set on variables.
    1179 Some of these phasers also have corresponding traits that can be set on variables.
    1176 1180 These have the advantage of passing the variable in question into
    1177 1181 the closure as its topic:
    1178 1182
     
    1184 1188 really traits, exactly--they add themselves onto a list stored in the
    1185 1189 actual trait (except for C<START>, which executes inline). So if you
    1186 1190 examine the C<ENTER> trait of a block, you'll find that it's really
    1187 a list of closures rather than a single closure.
    1191 a list of phasers rather than a single phaser.
    1188 1192
    1189 1193 The semantics of C<INIT> and C<START> are not equivalent to each
    1190 1194 other in the case of cloned closures. An C<INIT> only runs once for
     
    1212 1216 In particular, this means that C<START> can make use of any parameters
    1213 1217 passed in on the first call, whereas C<INIT> cannot.
    1214 1218
    1215 All of these trait blocks can see any previously declared lexical
    1219 All of these phaser blocks can see any previously declared lexical
    1216 1220 variables, even if those variables have not been elaborated yet when
    1217 1221 the closure is invoked (in which case the variables evaluate to an
    1218 1222 undefined value.)
     
    1225 1229 class block is executed, but C<PRE>/C<POST> in a class block are evaluated
    1226 1230 around every method in the class.) C<KEEP> and C<UNDO> are just variants
    1227 1231 of C<LEAVE>, and for execution order are treated as part of the queue of
    1228 C<LEAVE> blocks.
    1232 C<LEAVE> phasers.
    1229 1233
    1230 1234 C<FIRST>, C<NEXT>, and C<LAST> are meaningful only within the
    1231 1235 lexical scope of a loop, and may occur only at the top level of such
    1232 1236 a loop block. A C<NEXT> executes only if the end of the loop block is
    1233 1237 reached normally, or an explicit C<next> is executed. In distinction
    1234 to C<LEAVE> blocks, a C<NEXT> block is not executed if the loop block
    1238 to C<LEAVE> phasers, a C<NEXT> phaser is not executed if the loop block
    1235 1239 is exited via any exception other than the control exception thrown
    1236 1240 by C<next>. In particular, a C<last> bypasses evaluation of C<NEXT>
    1237 blocks.
    1241 phasers.
    1238 1242
    1239 1243 [Note: the name C<FIRST> used to be associated with C<state>
    1240 1244 declarations. Now it is associated only with loops. See the C<START>
    1241 1245 above for C<state> semantics.]
    1242 1246
    1243 C<LEAVE> blocks are evaluated after C<CATCH> and C<CONTROL> blocks, including
    1244 the C<LEAVE> variants, C<KEEP> and C<UNDO>. C<POST> blocks are evaluated after
    1245 everything else, to guarantee that even C<LEAVE> blocks can't violate DBC.
    1246 Likewise C<PRE> blocks fire off before any C<ENTER> or C<FIRST> (though not
    1247 C<LEAVE> phasers are evaluated after C<CATCH> and C<CONTROL> phasers, including
    1248 the C<LEAVE> variants, C<KEEP> and C<UNDO>. C<POST> phasers are evaluated after
    1249 everything else, to guarantee that even C<LEAVE> phasers can't violate DBC.
    1250 Likewise C<PRE> phasers fire off before any C<ENTER> or C<FIRST> (though not
    1247 1251 before C<BEGIN>, C<CHECK>, or C<INIT>, since those are done at compile or
    1248 1252 process initialization time).
    1249 1253
    1250 If an exception is thrown through a block without a C<CATCH> block, the
    1251 C<LEAVE>, C<UNDO> and C<POST> blocks will be run at that point, with
    1254 If an exception is thrown through a block without a C<CATCH> phaser, the
    1255 C<LEAVE>, C<UNDO> and C<POST> phasers will be run at that point, with
    1252 1256 C<$!> set to the in-flight exception. If there is no in-flight
    1253 exception when these blocks are run, C<$!> will be C<undef>. The last
    1257 exception when these phasers are run, C<$!> will be C<undef>. The last
    1254 1258 exception caught in the outer block is available as C<< OUTER::<$!> >>,
    1255 1259 as usual.
    1256 1260
    1257 An exception thrown from an C<ENTER> block will abort the C<ENTER>
    1258 queue, but one thrown from a C<LEAVE> block will not. The exceptions
    1259 thrown by failing C<PRE> and C<POST> blocks cannot be caught by a
    1260 C<CATCH> in the same block, which implies that C<POST> blocks are not
    1261 run if a C<PRE> block fails. If a C<POST> fails while an exception is in
    1261 An exception thrown from an C<ENTER> phaser will abort the C<ENTER>
    1262 queue, but one thrown from a C<LEAVE> phaser will not. The exceptions
    1263 thrown by failing C<PRE> and C<POST> phasers cannot be caught by a
    1264 C<CATCH> in the same block, which implies that C<POST> phaser are not
    1265 run if a C<PRE> phaser fails. If a C<POST> fails while an exception is in
    1262 1266 flight the C<POST> failure doesn't replace C<$!> but goes straight into
    1263 1267 C<$!.pending>.
    1264 1268
    1265 For blocks such as C<KEEP> and C<POST> that are run when exiting a
    1269 For phasers such as C<KEEP> and C<POST> that are run when exiting a
    1266 1270 scope normally, the return value (if any) from that scope is available
    1267 as the current topic. (It is presented as a C<Capture> object.)
    1271 as the current topic within the phaser. (It is presented as a C<Parcel> object.)
    1268 1272 The topic of the outer block is still available as C<< OUTER::<$_> >>.
    1269 Whether the return value is modifiable may be a policy of the block
    1273 Whether the return value is modifiable may be a policy of the phaser
    1270 1274 in question. In particular, the return value should not be modified
    1271 within a C<POST> block, but a C<LEAVE> block could be more liberal.
    1275 within a C<POST> phaser, but a C<LEAVE> phaser could be more liberal.
    1272 1276
    1273 1277 =head1 Statement parsing
    1274 1278