Revision 29004
- Date:
- 2009/11/06 17:35:03
- 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