NAME
Synopsis_4 - Blocks and Statements
AUTHOR
Larry Wall <larry@wall.org>
VERSION
Maintainer: Larry Wall <larry@wall.org>
Date: 19 Aug 2004
Last Modified: 7 Dec 2007
Number: 4
Version: 62This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl.
The Relationship of Blocks and Declarations
Every block is a closure. (That is, in the abstract, they're all anonymous subroutines that take a snapshot of their lexical scope.) How a block is invoked and how its results are used are matters of context, but closures all work the same on the inside.
Blocks are delimited by curlies, or by the beginning and end of the current compilation unit (either the current file or the current eval string). Unlike in Perl 5, there are (by policy) no implicit blocks around standard control structures. (You could write a macro that violates this, but resist the urge.) Variables that mediate between an outer statement and an inner block (such as loop variables) should generally be declared as formal parameters to that block. There are three ways to declare formal parameters to a closure.
$func = sub ($a, $b) { .print if $a eq $b }; # standard sub declaration
$func = -> $a, $b { .print if $a eq $b }; # a "pointy" block
$func = { .print if $^a eq $^b } # placeholder argumentsA bare closure without placeholder arguments that uses $_ (either explicitly or implicitly) is treated as though $_ were a formal parameter:
$func = { .print if $_ }; # Same as: $func = -> $_ { .print if $_ };
$func("printme");In any case, all formal parameters are the equivalent of my variables within the block. See S06 for more on function parameters.
Except for such formal parameter declarations, all lexically scoped declarations are visible from the point of declaration to the end of the enclosing block. Period. Lexicals may not "leak" from a block to any other external scope (at least, not without some explicit aliasing action on the part of the block, such as exportation of a symbol from a module). The "point of declaration" is the moment the compiler sees "my $foo", not the end of the statement as in Perl 5, so
my $x = $x;will no longer see the value of the outer $x; you'll need to say either
my $x = $OUTER::x;or
my $x = OUTER::<$x>;instead.
If you declare a lexical twice in the same scope, it is the same lexical:
my $x;
my $x;By default the second declaration will get a compiler warning. You may suppress this by modifying the first declaration with proto:
my proto $x;
...
while my $x = @x.shift {...} # no warning
while my $x = @x.shift {...} # no warningIf you've referred to $x prior to the first declaration, and the compiler tentatively bound it to $OUTER::x, then it's an error to declare it, and the compiler is required to complain at that point. If such use can't be detected because it is hidden in an eval, then it is erroneous, since the eval() compiler might bind to either $OUTER::x or the subsequently declared "my $x".
As in Perl 5, "our $foo" introduces a lexically scoped alias for a variable in the current package.
The new constant declarator introduces a lexically scoped name for a compile-time constant, either a variable or a 0-ary sub, which may be initialized with a pseudo-assignment:
constant Num $pi = 3;
constant Num π = atan(2,2) * 4;The initializing expression is evaluated at BEGIN time.
There is a new state declarator that introduces a lexically scoped variable like my does, but with a lifetime that persists for the life of the closure, so that it keeps its value from the end of one call to the beginning of the next. Separate clones of the closure get separate state variables.
Perl 5's "local" function has been renamed to temp to better reflect what it does. There is also a let function that sets a hypothetical value. It works exactly like temp, except that the value will be restored only if the current block exits unsuccessfully. (See Definition of Success below for more.) temp and let temporize or hypotheticalize the value or the variable depending on whether you do assignment or binding. One other difference from Perl 5 is that the default is not to undefine a variable. So
temp $x;causes $x to start with its current value. Use
temp undefine $x;to get the Perl 5 behavior.
Note that temporizations that are undone upon scope exit must be prepared to be redone if a continuation within that scope is taken.
The Relationship of Blocks and Statements
The return value of a block is the value of its final statement. (This is subtly different from Perl 5's behavior, which was to return the value of the last expression evaluated, even if that expression was just a conditional.)
Statement-ending blocks
A line ending with a closing brace "}", followed by nothing but whitespace or comments, will terminate a statement if an end of statement can occur there. That is, these two statements are equivalent:
my $x = sub { 3 }
my $x = sub { 3 };End-of-statement cannot occur within a bracketed expression, so this still works:
my $x = [
sub { 3 }, # this comma is not optional
sub { 3 } # the statement won't terminate here
];However, a hash composer may never occur at the end of a line. If the parser sees anything that looks like a hash composer at the end of the line, it fails with "closing hash curly may not terminate line" or some such.
my $hash = {
1 => { 2 => 3, 4 => 5 }, # OK
2 => { 6 => 7, 8 => 9 } # ERROR
};Because subroutine declarations are expressions, not statements, this is now invalid:
sub f { 3 } sub g { 3 } # two terms occur in a rowBut these two are valid:
sub f { 3 }; sub g { 3 };
sub f { 3 }; sub g { 3 } # the trailing semicolon is optionalThough certain control statements could conceivably be parsed in a self-contained way, for visual consistency all statement-terminating blocks that end in the middle of a line must be terminated by semicolon unless they are naturally terminated by some other statement terminator:
while yin() { yang() } say "done"; # ILLEGAL
while yin() { yang() }; say "done"; # okay, explicit semicolon
@yy := [ while yin() { yang() } ]; # okay within outer [...]
while yin() { yang() } ==> sort # okay, ==> separates statementsConditional statements
The if and unless statements work much as they do in Perl 5. However, you may omit the parentheses on the conditional:
if $foo == 123 {
...
}
elsif $foo == 321 {
...
}
else {
...
}If the final statement is a conditional which does not execute any branch, the return value is undef in item context and () in list context.
The unless statement does not allow an elsif or else in Perl 6.
The value of the conditional expression may be optionally bound to a closure parameter:
if testa() -> $a { say $a }
elsif testb() -> $b { say $b }
else -> $b { say $b }Note that the value being evaluated for truth and subsequently bound is not necessarily a value of type Bool. (All normal types in Perl may be evaluated for truth. In fact, this construct would be relatively useless if you could bind only boolean values as parameters, since within the closure you already know whether it evaluated to true or false.) Binding within an else automatically binds the value tested by the previous if or elsif, which, while known to be false, might nevertheless be an interesting value of false. (By similar reasoning, an unless allows binding of a false parameter.)
An explicit placeholder may also be used:
if blahblah() { return $^it }However, use of $_ with a conditional statement's block is not considered sufficiently explicit to turn a 0-ary block into a 1-ary function, so both these methods use the same invocant:
if .haste { .waste }(Contrast with a non-conditional statement such as:
for .haste { .waste }where each call to the block would bind a new invocant for the .waste method, each of which is likely different from the original invocant to the .haste method.)
Conditional statement modifiers work as in Perl 5. So do the implicit conditionals implied by short-circuit operators. Note though that the first expression within parens or brackets is parsed as a statement, so you can say:
@x = 41, (42 if $answer), 43;and that is equivalent to:
@x = 41, ($answer ?? 42 !! ()), 43Loop statements
Looping statement modifiers are the same as in Perl 5 except that, for ease of writing list comprehensions, a looping statement modifier is allowed to contain a single conditional statement modifier:
@evens = ($_ * 2 if .odd for 0..100);Loop modifiers next, last, and redo also work as in Perl 5. However, the labelled forms use method call syntax: LABEL.next, etc. The .next and .last methods take an optional argument giving the final value of that loop iteration. So the old next LINE syntax is still allowed but is really short for next LINE: using indirect object syntax. Any block object can be used, not just labels, so to return a value from this iteration of the current block you can say:
&?BLOCK.next($retval);[Conjecuture: a bare next($retval) function could be taught to do the same, as long as $retval isn't a loop label. Presumably multiple dispatch could sort this out.]
There is no longer a continue block. Instead, use a NEXT block within the body of the loop. See below.
The value of a loop statement is the list of values from each iteration. Iterations that return a null list (such as by calling next with no extra return arguments) interpolate no values in the resulting list. (This list is actually a two-dimensional list of Captures (a "slice") with dimensional boundaries at each iteration. Normal list context ignores these boundaries and flattens the list. Slice context turns the captures into subarrays, so an iteration returning a null list does show up as a null subarray when viewed as a slice.)
For finer-grained control of which iterations return values, use gather and take.
Since the final expression in a subroutine returns its value, it's possible to accidentally return a loop's return value when you were only evaluating the loop for its side effects. If you do not wish to accidentally return a list from the final loop statement in a subroutine, place an explicit return statement after it, or declare a return type of Void.
The while and until statements
The while and until statements work as in Perl 5, except that you may leave out the parentheses around the conditional:
while $bar < 100 {
...
}As with conditionals, you may optionally bind the result of the conditional expression to a parameter of the block:
while something() -> $thing {
...
}
while something() -> { ... $^thing ... }Nothing is ever bound implicitly, however, and many conditionals would simply bind True or False in an uninteresting fashion. This mechanism is really only good for objects that know how to return a boolean value and still remain themselves. In general, for most iterated solutions you should consider using a for loop instead (see below). In particular, we now generally use for to iterate filehandles.
The repeat statement
Unlike in Perl 5, applying a statement modifier to a do block is specifically disallowed:
do {
...
} while $x < 10; # ILLEGALInstead, you should write the more Pascal-like repeat loop:
repeat {
...
} while $x < 10;or equivalently:
repeat {
...
} until $x >= 10;Unlike Perl 5's do-while loop, this is a real loop block now, so next, last, and redo work as expected. The loop conditional on a repeat block is required, so it will be recognized even if you put it on a line by its own:
repeat
{
...
}
while $x < 10;However, that's likely to be visually confused with a following while loop at the best of times, so it's also allowed to put the loop conditional at the front, with the same meaning. (The repeat keyword forces the conditional to be evaluated at the end of the loop, so it's still C's do-while semantics.) Therefore, even under GNU style rules, the previous example may be rewritten into a very clear:
repeat while $x < 10
{
...
}or equivalently:
repeat until $x >= 10
{
...
}As with an ordinary while, you may optionally bind the result of the conditional expression to a parameter of the block:
repeat -> $thing {
...
} while something();or
repeat while something() -> $thing {
...
}Since the loop executes once before evaluating the condition, the bound parameter will be undefined that first time through the loop.
The general loop statement
The loop statement is the C-style for loop in disguise:
loop ($i = 0; $i < 10; $i++) {
...
}As in C, the parentheses are required if you supply the 3-part spec; however, the 3-part loop spec may be entirely omitted to write an infinite loop. That is,
loop {...}is equivalent to the Cish idiom:
loop (;;) {...}The for statement
There is no foreach statement any more. It's always spelled for in Perl 6, so it always takes a list as an argument:
for @foo { .print }As mentioned earlier, the loop variable is named by passing a parameter to the closure:
for @foo -> $item { print $item }Multiple parameters may be passed, in which case the list is traversed more than one element at a time:
for %hash.kv -> $key, $value { print "$key => $value\n" }To process two arrays in parallel use the zip function to generate a list that can be bound to the corresponding number of parameters:
for zip(@a;@b) -> $a, $b { print "[$a, $b]\n" }
for @a Z @b -> $a, $b { print "[$a, $b]\n" } # same thingThe list is evaluated lazily by default, so instead of using a while to read a file a line at a time as you would in Perl 5:
while (my $line = <STDIN>) {...}in Perl 6 you should use a for (plus a unary = "iterate the iterator" operator) instead:
for =$*IN -> $line {...}This has the added benefit of limiting the scope of the $line parameter to the block it's bound to. (The while's declaration of $line continues to be visible past the end of the block. Remember, no implicit block scopes.) It is also possible to write
while =$*IN -> $line {...}Note also that Perl 5's special rule causing
while (<>) {...}to automatically assign to $_ is not carried over to Perl 6. That should now be written:
for =<> {...}which is short for
for =$*ARGS {...}Arguments bound to the formal parameters of a pointy block are by default readonly within the block. You can declare a parameter read/write by including the "is rw" trait. The following treats every other value in @values as modifiable:
for @values -> $even is rw, $odd { ... }In the case where you want all your parameters to default to rw, you may use the visually suggestive double-ended arrow to indicate that values flow both ways:
for @values <-> $even, $odd { ... }This is equivalent to
for @values -> $even is rw, $odd is rw { ... }If you rely on $_ as the implicit parameter to a block, then $_ is considered read/write by default. That is, the construct:
for @foo {...}is actually short for:
for @foo <-> $_ {...}so you can modify the current list element in that case.
When used as statement modifiers, for and given use a private instance of $_ for the left side of the statement. The outer $_ can be referred to as $OUTER::_. (And yes, this implies that the compiler may have to retroactively change the binding of <$_> on the left side. But it's what people expect of a pronoun like "it".)
The do-once loop
In Perl 5, a bare block is deemed to be a do-once loop. In Perl 6, the bare block is not a do-once. Instead do {...} is the do-once loop (which is another reason you can't put a statement modifier on it; use repeat for a test-at-the-end loop).
For any statement, prefixing with a do allows you to return the value of that statement and use it in an expression:
$x = do if $a { $b } else { $c };This construct only allows you to attach a single statement to the end of an expression. If you want to continue the expression after the statement, or if you want to attach multiple statements. you must either use the curly form or surround the entire expression in brackets of some sort:
@primes = (do (do $_ if .prime) for 1..100);Since a bare expression may be used as a statement, you may use do on an expression, but its only effect is to function as an unmatched left parenthesis, much like the $ operator in Haskell. That is, precedence decisions do not cross a do boundary, and the missing "right paren" is assumed at the next statement terminator or unmatched bracket. A do is assumed immediately after any opening bracket, so the above can in fact be written:
@primes = (($_ if .prime) for 1..100);This basically gives us list comprehensions as rvalue expressions:
(for 1..100 { $_ if .prime}).saySince do is defined as going in front of a statement, it follows that it can always be followed by a statement label. This is particularly useful for the do-once block, since it is offically a loop and can take therefore loop control statements.
Although a bare block is no longer a do-once loop, it still executes immediately as in Perl 5, as if it were immediately dereferenced with a .() postfix, so within such a block CALLER:: refers to the scope surrounding the block. If you wish to return a closure from a function, you must use an explicit prefix such as return or sub or ->. (Use of a placeholder parameter is deemed insufficiently explicit because it's not out front where it can be seen. You can, of course, use a placeholder parameter if you also use return.)
Another consequence of this is that any block just inside a left parenthesis is immediately called like a bare block, so a multidimensional list comprehension may be written using a block with multiple parameters fed by a for modifier:
@names = (-> $name, $num { "$name.$num" } for 'a'..'zzz' X 1..100);or equivalently, using placeholders:
@names = ({ "$^name.$^num" } for 'a'..'zzz' X 1..100);The gather statement
A variant of do is gather. Like do, it is followed by a statement or block, and executes it once. Unlike do, it evaluates the statement or block in void context; its return value is instead specified by calling the take list prefix operator one or more times within the dynamic scope of the gather. The take function's signature is like that of return; it merely captures the Capture of its argments without imposing any additional constraints (in the absence of context propagation by the optimizer). The value returned by the take to its own context is that same Capture object (which is ignored when the take is in void context). Regardless of the take's context, the Capture object is also added to the list of values being gathered, which is returned by the gather in the form of a lazy slice, with each slice element corresponding to one take capture. (A list of Captures is lazily flattened in normal list context, but you may "unflatten" it again with a @@() contextualizer.)
Because gather evaluates its block or statement in void context, this typically causes the take function to be evaluated in void context. However, a take function that is not in void context gathers its arguments en passant and also returns them unchanged. This makes it easy to keep track of what you last "took":
my @uniq = gather for @list {
state $previous = take $_;
next if $_ === $previous;
$previous = take $_;
}The take function essentially has two contexts simultaneously, the context in which the gather is operating, and the context in which the take is operating. These need not be identical contexts, since they may bind or coerce the resulting captures differently:
my @y;
@x = gather for 1..2 { # @() context for list of captures
my $x = take $_, $_ * 10; # $() context for individual capture
push @y, $x;
}
# @x returns 1,10,2,20
# @y returns [1,10],[2,20]Likewise, we can just remember the gather's result by binding and later coerce it:
$c := gather for 1..2 {
take $_, $_ * 10;
}
# @$c returns 1,10,2,20
# @@$c returns [1,10],[2,20]
# $$c returns [[1,10],[2,20]]Note that the take itself is in void context in this example because the for loop is in void context.
A gather is not considered a loop, but it is easy to combine with a loop statement as in the examples above.
If any function called as part of a take list asks what its context is, it will be told it was called in list context regardless of the eventual binding of the returned Capture. If that is not the desired behavior you must coerce the call to an appropriate context. In any event, such a function is called only once at the time the Capture object is generated, not when it is bound (which could happen more than once).
Other do-like forms
Other similar Code-only forms may also take bare statements, including try, contend, async, and lazy. These constructs establish a dynamic scope without necessarily establishing a lexical scope. (You can always establish a lexical scope explicitly by using the block form of argument.) As statement introducers, all these keywords must be followed by whitespace. You can say something like try({...}), but then you are calling it using function call syntax instead, in which case the Code argument must be a block. For purposes of flow control, none of these forms are considered loops, but they may easily be applied to a normal loop.
Switch statements
A switch statement is a means of topicalizing, so the switch keyword is the English topicalizer, given. The keyword for individual cases is when:
given EXPR {
when EXPR { ... }
when EXPR { ... }
default { ... }
}The current topic is always aliased to the special variable $_. The given block is just one way to set the current topic, but a switch statement can be any block that sets $_, including a for loop (assuming one of its loop variables is bound to $_) or the body of a method (if you have declared the invocant as $_). So switching behavior is actually caused by the when statements in the block, not by the nature of the block itself. A when statement implicitly does a "smart match" between the current topic ($_) and the argument of the when. If the smart match succeeds, when's associated block is executed, and the innermost surrounding block that has $_ as one of its formal parameters (either explicit or implicit) is automatically broken out of. (If that is not the block you wish to leave, you must use the LABEL.leave method (or some other control exception such as return or next) to be more specific, since the compiler may find it difficult to guess which surrounding construct was intended as the actual topicalizer.) The value of the inner block is returned as the value of the outer block.
If the smart match fails, control passes to the next statement normally, which may or may not be a when statement. Since when statements are presumed to be executed in order like normal statements, it's not required that all the statements in a switch block be when statements (though it helps the optimizer to have a sequence of contiguous when statements, because then it can arrange to jump directly to the first appropriate test that might possibly match.)
The default case:
default {...}is exactly equivalent to
when * {...}Because when statements are executed in order, the default must come last. You don't have to use an explicit default--you can just fall off the last when into ordinary code. But use of a default block is good documentation.
If you use a for loop with a parameter named $_ (either explicitly or implicitly), that parameter can function as the topic of any when statements within the loop.
You can explicitly break out of a when block (and its surrounding topicalizer block) early using the break verb. More precisely, it leaves the innermost block outside the when that uses $_ as one of its formal parameters, either explicitly or implicitly. It does this essentially by going to the end of the block and returning normally from that block. In other words, a break (either implicit or explicit) is assumed to indicate success, not failure.
You can explicitly leave a when block and go to the next statement following the when by using continue. (Note that, unlike C's idea of "falling through", subsequent when conditions are evaluated. To jump into the next when block without testing its condition, you must use a goto.)
If you have a switch that is the main block of a for loop, and you break out of the switch either implicitly or explicitly (that is, the switch "succeeds"), control merely goes to the end of that block, and thence on to the next iteration of the loop. You must use last (or some more violent control exception such as return) to break out of the entire loop early. Of course, an explicit next might be clearer than a break if you really want to go directly to the next iteration. On the other hand, break can take an optional argument giving the value for that iteration of the loop. As with the .leave method, there is also a .break method to break from a labelled block functioning as a switch:
OUTER.break($retval)Exception handlers
Unlike many other languages, Perl 6 specifies exception handlers by placing a CATCH block within that block that is having its exceptions handled.
The Perl 6 equivalent to Perl 5's eval {...} is try {...}. (Perl 6's eval function only evaluates strings, not blocks.) A try block by default has a CATCH block that handles all exceptions by ignoring them. If you define a CATCH block within the try, it replaces the default CATCH. It also makes the try keyword redundant, because any block can function as a try block if you put a CATCH block within it.
An exception handler is just a switch statement on an implicit topic supplied within the CATCH block. That implicit topic is the current exception object, also known as $!. Inside the CATCH block, it's also bound to $_, since it's the topic. Because of smart matching, ordinary when statements are sufficiently powerful to pattern match the current exception against classes or patterns or numbers without any special syntax for exception handlers. If none of the cases in the CATCH handles the exception, the exception is rethrown. To ignore all unhandled exceptions, use an empty default case. (In other words, there is an implicit die $! just inside the end of the CATCH block. Handled exceptions break out past this implicit rethrow.)
A CATCH block sees the lexical scope in which it was defined, but its caller is the dynamic location that threw the exception. That is, the stack is not unwound until some exception handler chooses to unwind it by "handling" the exception in question. So logically, if the CATCH block throws its own exception, you would expect the CATCH block to catch its own exception recursively forever. However, a CATCH must not behave that way, so we say that a CATCH block never attempts to handle any exception thrown within its own dynamic scope. (Otherwise the die in the previous paragraph would never work.)
Control Exceptions
All abnormal control flow is, in the general case, handled by the exception mechanism (which is likely to be optimized away in specific cases.) Here "abnormal" means any transfer of control outward that is not just falling off the end of a block. A return, for example, is considered a form of abnormal control flow, since it can jump out of multiple levels of closures to the end of the scope of the current subroutine definition. Loop commands like next are abnormal, but looping because you hit the end of the block is not. The implicit break of a when block is abnormal.
A CATCH block handles only "bad" exceptions, and lets control exceptions pass unhindered. Control exceptions may be caught with a CONTROL block. Generally you don't need to worry about this unless you're defining a control construct. You may have one CATCH block and one CONTROL block, since some user-defined constructs may wish to supply an implicit CONTROL block to your closure, but let you define your own CATCH block.
A return always exits from the lexically surrounding sub or method definition (that is, from a function officially declared with the sub, method, or submethod keywords). Pointy blocks and bare closures are transparent to return. If you pass a closure object outside of its official "sub" scope, it is illegal to return from it. You may only leave the displaced closure block itself by falling off the end of it or by explicitly calling leave.
To return a value from any pointy block or bare closure, you either just let the block return the value of its final expression, or you can use leave, which comes in both function and method forms. The function (or listop) form always exits from the innermost block, returning its arguments as the final value of the block exactly as return does. The method form will leave any block in the dynamic scope that can be named as an object and that responds to the .leave method.
Hence, the leave function:
leave(1,2,3)is really just short for:
&?BLOCK.leave(1,2,3)To return from your immediate caller, you can say:
caller.leave(1,2,3)Further contexts up the caller stack may be located by use of the context function:
context({ .labels.any eq 'LINE' }).leave(1,2,3);By default the innermost dynamic scope matching the selection criteria will be exited. This can be a bit cumbersome, so in the particular case of labels, the label that is already visible in the current lexical scope is considered a kind of pseudo object specifying a potential dynamic context. If instead of the above you say:
LINE.leave(1,2,3)it was always exit from your lexically scoped LINE loop, even if some inner dynamic scope you can't see happens to also have that label. If the LINE label is visible but you aren't actually in a dynamic scope controlled by that label, an exception is thrown. (If the LINE is not visible, it would have been caught earlier at compile time since LINE would likely be a bareword.)
In theory, any user-defined control construct can catch any control exception it likes. However, there have to be some culturally enforced standards on which constructs capture which exceptions. Much like return may only return from an "official" subroutine or method, a loop exit like next should be caught by the construct the user expects it to be caught by. In particular, if the user labels a loop with a specific label, and calls a loop control from within the lexical scope of that loop, and if that call mentions the outer loop's label, then that outer loop is the one that must be controlled. In other words, it first tries this form:
LINE.leave(1,2,3)If there is no such lexically scoped outer loop in the current subroutine, then a fallback search is made outward through the dynamic scopes in the same way Perl 5 does. (The difference between Perl 5 and Perl 6 in this respect arises only because Perl 5 didn't have user-defined control structures, hence the sub's lexical scope was always the innermost dynamic scope, so the preference to the lexical scope in the current sub was implicit. For Perl 6 we have to make this preference explicit.) So this fallback is more like the context form we saw earlier.
Warnings are produced in Perl 6 by throwing a resumable control exception to the outermost scope, which by default prints the warning and resumes the exception by extracting a resume continuation from the exception, which must be supplied by the warn() function (or equivalent). Exceptions are not resumable in Perl 6 unless the exception object does the Resumable role. (Note that fatal exception types can do the Resumable role even if thrown via fail()--when uncaught they just hit the outermost fatal handler instead of the outermost warning handler, so some inner scope has to explicitly treat them as warnings and resume them.)
Since warnings are processed using the standard control exception mechanism, they may be intercepted and either suppressed or fatalized anywhere within the dynamic scope by supplying a suitable CONTROL block. This dynamic control is orthogonal to any lexically scoped warning controls, which merely decide whether to call warn() in the first place.
As with calls to return, the warning control exception is an abstraction that the compiler is free to optimize away (along with the associated continuation) when the compiler or runtime can determine that the semantics would be preserved by merely printing out the error and going on. Since all exception handlers run in the dynamic context of the throw, that reduces to simply returning from the warn function most of the time.
The goto statement
In addition to next, last, and redo, Perl 6 also supports goto. As with ordinary loop controls, the label is searched for first lexically within the current subroutine, then dynamically outside of it. Unlike with loop controls, however, scanning a scope includes a scan of any lexical scopes included within the current candidate scope. As in Perl 5, it is possible to goto into a lexical scope, but only for lexical scopes that require no special initialization of parameters. (Initialization of ordinary variables does not count--presumably the presence of a label will prevent code-movement optimizations past the label.) So, for instance, it's always possible to goto into the next case of a when or into either the "then" or "else" branch of a conditional. You may not go into a given or a for, though, because that would bypass a formal parameter binding (not to mention list generation in the case of for). (Note: the implicit default binding of an outer $_ to an inner $_ can be emulated for a bare block, so that doesn't fall under the prohibition on bypassing formal binding.)
Exceptions
As in Perl 5, many built-in functions simply return undef when you ask for a value out of range, or the function fails somehow. Perl 6 has Failure objects, any of which refers to an unthrown Exception object in $! and knows whether it has been handled or not.
If you test a Failure for .defined or .true, it causes $! to mark the exception as handled, and acts as a harmless Undef value thereafter. Any other use of the Failure will throw its associated exception immediately.
Because the contextual variable $! contains all exceptions collected in the current lexical scope, saying die $! will throw all exceptions, whether they were handled or not. A bare die/fail takes $! as the default argument.
At scope exit, $! discards all handled exceptions from itself, then performs a garbage-collection check for all remaining (unhandled) exceptions. If all of them are still alive (e.g. by becoming part of the return value), then they are appended to CALLER::<$!>. Otherwise, it calls die to throw those exceptions as a single new exception, which may then be caught with a CATCH block in the current (or caller's) scope.
You can cause built-ins to automatically throw exceptions on failure using
use fatal;The fail function responds to the caller's use fatal state. It either returns an unthrown exception, or throws the exception.
Closure traits
A CATCH block is just a trait of the closure containing it. Other blocks can be installed as traits as well. These other blocks are called at various times, and some of them respond to various control exceptions and exit values:
BEGIN {...}* at compile time, ASAP, only ever runs once
CHECK {...}* at compile time, ALAP, only ever runs once
INIT {...}* at run time, ASAP, only ever runs once
END {...} at run time, ALAP, only ever runs once
START {...}* on first ever execution, once per closure clone
ENTER {...}* at every block entry time, repeats on loop blocks.
LEAVE {...} at every block exit time
KEEP {...} at every successful block exit, part of LEAVE queue
UNDO {...} at every unsuccessful block exit, part of LEAVE queue
FIRST {...}* at loop initialization time, before any ENTER
NEXT {...} at loop continuation time, before any LEAVE
LAST {...} at loop termination time, after any LEAVE
PRE {...} assert precondition at every block entry, before ENTER
POST {...} assert postcondition at every block exit, after LEAVE
CATCH {...} catch exceptions, before LEAVE
CONTROL {...} catch control exceptions, before LEAVEThose marked with a * can also be used within an expression:
my $compiletime = BEGIN { localtime };
our $temphandle = START { maketemp() };Code that is generated at run time can still fire off CHECK and INIT blocks, though of course those blocks can't do things that would require travel back in time.
Some of these also have corresponding traits that can be set on variables. These have the advantage of passing the variable in question into the closure as its topic:
my $r will start { .set_random_seed() };
our $h will enter { .rememberit() } will undo { .forgetit() };Apart from CATCH and CONTROL, which can only occur once, most of these can occur multiple times within the block. So they aren't really traits, exactly--they add themselves onto a list stored in the actual trait (except for START, which executes inline). So if you examine the ENTER trait of a block, you'll find that it's really a list of closures rather than a single closure.
The semantics of INIT and START are not equivalent to each other in the case of cloned closures. An INIT only runs once for all copies of a cloned closure. A START runs separately for each clone, so separate clones can keep separate state variables:
our $i = 0;
...
$func = { state $x will start { $x = $i++ }; dostuff($i) };But state automatically applies "start" semantics to any initializer, so this also works:
$func = { state $x = $i++; dostuff($i) }Each subsequent clone gets an initial state that is one higher than the previous, and each clone maintains its own state of $x, because that's what state variables do.
Even in the absence of closure cloning, INIT runs before the mainline code, while START puts off the initialization till the last possible moment, then runs exactly once, and caches its value for all subsequent calls (assuming it wasn't called in void context, in which case the START is evaluated once only for its side effects).
All of these trait blocks can see any previously declared lexical variables, even if those variables have not been elaborated yet when the closure is invoked (in which case the variables evaluate to an undefined value.)
Note: Apocalypse 4 confused the notions of PRE/POST with ENTER/LEAVE. These are now separate notions. ENTER and LEAVE are used only for their side effects. PRE and POST must return boolean values that are evaluated according to the usual Design by Contract (DBC) rules. (Plus, if you use ENTER/LEAVE in a class block, they only execute when the class block is executed, but PRE/POST in a class block are evaluated around every method in the class.) KEEP and UNDO are just variants of LEAVE, and for execution order are treated as part of the queue of LEAVE blocks.
FIRST, NEXT, and LAST are meaningful only within the lexical scope of a loop, and may occur only at the top level of such a loop block. A NEXT executes only if the end of the loop block is reached normally, or an explicit next is executed. In distinction to LEAVE blocks, a NEXT block is not executed if the loop block is exited via any exception other than the control exception thrown by next. In particular, a last bypasses evaluation of NEXT blocks.
[Note: the name FIRST used to be associated with state declarations. Now it is associated only with loops. See the START above for state semantics.]
LEAVE blocks are evaluated after CATCH and CONTROL blocks, including the LEAVE variants, KEEP and UNDO. POST blocks are evaluated after everything else, to guarantee that even LEAVE blocks can't violate DBC. Likewise PRE blocks fire off before any ENTER or FIRST (though not before BEGIN, CHECK, or INIT, since those are done at compile or process initialization time).
Statement parsing
In this statement:
given EXPR {
when EXPR { ... }
when EXPR { ... }
...
}parentheses aren't necessary around EXPR because the whitespace between EXPR and the block forces the block to be considered a block rather than a subscript. This works for all control structures, not just the new ones in Perl 6. A top-level bare block is always considered a statement block if there's space before it:
if $foo { ... }
elsif $bar { ... }
else { ... }
while $more { ... }
for 1..10 { ... }You can still parenthesize the expression argument for old times' sake, as long as there's a space between the closing paren and the opening brace. You must parenthesize the expression if there is a bare block or pointy block that would be misinterpreted as the statement's block. This is regardless of whether a term or operator is expected where the block occurs. (A block inside brackets, or used as a postcircumfix is fine, though.) Any block with whitespace in front of it will be taken as terminating the conditional, even if the conditional expression could take another argument. Therefore
if rand { say "exists" } { extra() }
if rand -> $x { say "exists" } { extra() }is always parsed as
if (rand) { say "exists" }; { extra() }
if (rand) -> $x { say "exists" }; { extra() }rather than
if (rand { say "exists" }) { extra() }
if (rand (-> $x { say "exists" })) { extra() }Apart from that, it is illegal to use a bare closure where an operator is expected. (Remove the whitespace if you wish it to be a postcircumfix.)
Anywhere a term is expected, a block is taken to be a closure definition (an anonymous subroutine). If the closure is empty, or appears to contain nothing but a comma-separated list starting with a pair or a hash (counting a single pair or hash as a list of one element), the closure will be immediately executed as a hash composer.
$hash = { };
$hash = { %stuff };
$hash = { "a" => 1 };
$hash = { "a" => 1, $b, $c, %stuff, @nonsense };
$code = { ; };
$code = { @stuff };
$code = { "a", 1 };
$code = { "a" => 1, $b, $c ==> print };If you wish to be less ambiguous, the hash list operator will explicitly evaluate a list and compose a hash of the returned value, while sub introduces an anonymous subroutine:
$code = sub { "a" => 1 };
$hash = hash("a" => 1);
$hash = hash("a", 1);If a closure is the right argument of the dot operator, the closure is interpreted as a hash subscript.
$code = {$x}; # closure because term expected
if $term{$x} # subscript because postfix expected
if $term {$x} # expression followed by statement block
if $term.{$x} # valid subscript with dot
if $term\ .{$x} # valid subscript with "unspace"Similar rules apply to array subscripts:
$array = [$x]; # array composer because term expected
if $term[$x] # subscript because postfix expected
if $term [$x] # syntax error (two terms in a row)
if $term.[$x] # valid subscript with dot
if $term\ .[$x] # valid subscript with "unspace"And to the parentheses delimiting function arguments:
$scalar = ($x); # grouping parens because term expected
if $term($x) # function call because operator expected
if $term ($x) # syntax error (two terms in a row)
if $term.($x) # valid function call with dot
if $term\ .($x) # valid function call with "unspace"Outside of any kind of expression brackets, a final closing curly on a line (not counting whitespace or comments) always reverts to the precedence of semicolon whether or not you put a semicolon after it. (In the absence of an explicit semicolon, the current statement may continue on a subsequent line, but only with valid statement continuators such as else that cannot be confused with the beginning of a new statement. Anything else, such as a statement modifier (on, say, a loop statement) must continue on the same line, unless the newline be escaped using the "unspace" construct--see S02.)
Final blocks on statement-level constructs always imply semicolon precedence afterwards regardless of the position of the closing curly. Statement-level constructs are distinguished in the grammar by being declared in the statement_control category:
macro statement_control:<if> ($expr, &ifblock) {...}
macro statement_control:<while> ($expr, &whileblock) {...}
macro statement_control:<BEGIN> (&beginblock) {...}Statement-level constructs may start only where the parser is expecting the start of a statement. To embed a statement in an expression you must use something like do {...} or try {...}.
$x = do { given $foo { when 1 {2} when 3 {4} } } + $bar;
$x = try { given $foo { when 1 {2} when 3 {4} } } + $bar;The existence of a statement_control:<BEGIN> does not preclude us from also defining a prefix:<BEGIN> that can be used within an expression:
macro prefix:<BEGIN> (&beginblock) { beginblock().repr }Then you can say things like:
$recompile_by = BEGIN { time } + $expiration_time;But statement_control:<BEGIN> hides prefix:<BEGIN> at the start of a statement. You could also conceivably define a prefix:<if>, but then you may not get what you want when you say:
die if $foo;since prefix:<if> would hide statement_modifier:<if>.
Built-in statement-level keywords require whitespace between the keyword and the first argument, as well as before any terminating loop. In particular, a syntax error will be reported for C-isms such as these:
if(...) {...}
while(...) {...}
for(...) {...}Definition of Success
Hypothetical variables are somewhat transactional--they keep their new values only on successful exit of the current block, and otherwise are rolled back to their original values.
It is, of course, a failure to leave the block by propagating an error exception, though returning a defined value after catching an exception is okay.
In the absence of error exception propagation, a successful exit is one that returns a defined value in scalar context, or any number of values in list context as long as the length is defined. (A length of +Inf is considered a defined length. A length of 0 is also a defined length, which means it's a "successful" return even though the list would evaluate to false in a boolean context.) A list can have a defined length even if it contains undefined scalar values. A list is of undefined length only if it contains an undefined generator, which, happily, is what is returned by the fail function when used in list context. So any Perl 6 function can say
fail "message";and not care about whether the function is being called in scalar or list context. To return an explicit scalar undef, you can always say
return undef;Then in list context, you're returning a list of length 1, which is defined (much like in Perl 5). But generally you should be using fail in such a case to return an exception object. In any case, returning an unthrown exception is considered failure from the standpoint of let. Backtracking over a closure in a regex is also considered failure of the closure, which is how hypothetical variables are managed by regexes. (And on the flip side, use of fail within a regex closure initiates backtracking of the regex.)
When is a closure not a closure
Everything is conceptually a closure in Perl 6, but the optimizer is free to turn unreferenced closures into mere blocks of code. It is also free to turn referenced closures into mere anonymous subroutines if the block does not refer to any external lexicals that should themselves be cloned. In particular, named subroutines in any scope do not consider themselves closures unless you take a reference to them. So
sub foo {
my $x = 1;
my sub bar { print $x } # not cloned yet
my &baz = { bar(); print $x }; # cloned immediately
my $code = &bar; # now bar is cloned
return &baz;
}When we say "clone", we mean the way the system takes a snapshot of the routine's lexical scope and binds it to the current instance of the routine so that if you ever use the current reference to the routine, it gets the current snapshot of its world, lexically speaking.
Some closures produce Code objects at compile time that cannot be cloned, because they're not attached to any runtime code that can actually clone them. BEGIN, CHECK, INIT, and END blocks fall into this category. Therefore you can't reliably refer to run-time variables from these closures even if they appear to be in the scope. (The compile-time closure may, in fact, see some kind of permanent copy of the variable for some storage classes, but the variable is likely to be undefined when the closure is run in any case.) It's only safe to refer to package variables and file-scoped lexicals from such a routine.
On the other hand, it is required that CATCH and LEAVE blocks be able to see transient variables in their current lexical scope, so their cloning status depends at least on the cloning status of the block they're in.