Added: Dec 1, 2008
From: h4ck3rm1k3
Duration: 6:11
http://www.perlfoundation.org/perl6 - - stream as a funny kind of string. So if the "given" of a switch statement is a token stream, the regular expressions matched against it may have special abilities relating to the current parse's data structure. All the regular expressions of such a switch statement will likely be implicitly anchored to the current parse location, for instance. There may be special tokens referring to terminals and non-terminals. Basically, think of something like a yacc grammar, where alternative pattern/ action grammar rules are most naturally expressed via switch statement cases. More on that in the next Apocalypse. [Update: Parsing rules tend to use the ":p" modifier, which anchors the next token automatically to the start of the rule. That's all that needs to be user visible. Everything else is the domain of the optimizer.] Another possible adjustment is that the proposed "else" block could be considered unnecessary. The code following the final "when" is automatically an "else". Here's a duodecimal digit converter: $result = given $digit { when "T" { 10 } when "E" { 11 } $digit; } Nevertheless, it's probably good documentation to line up all the blocks, which means it would be good to have a keyword. However, for reasons that will become clearer when we talk about exception handlers, I don't want to use "else". Also, because of the identification of "when" and "if", it would not be clear whether an "else" should automatically supply a "break" at the end of its block as the ordinary "when" case does. So instead of "else", I'd like to borrow a bit more from C and use "default": $result = given $digit { when "T" { 10 } when "E" { 11 } default { $digit } } Unlike in C, the "default" case must come last, since Perl's cases are evaluated (or at least pretend to be evaluated) in order. The optimizer can often determine which cases can be jumped to directly, but in cases where that can't be determined, the cases are evaluated in order much like cascaded "if"/ "elsif"/"else" conditions. Also, it's allowed to intersperse ordinary code between the cases, in which case the code must be executed only if the cases above it fail to match. For example, this should work as indicated by the print statements: given $given { print "about to check $first"; when $first { ... } print "didn't match $first; let's try $next"; when $next { ... } print "giving up"; default { ... } die "panic: shouldn't see this"; } We can still define "when" as a variant of "if", which makes it possible to intermix the two constructs when (or if) that is desirable. So we'll leave that identity in--it always helps people think about it when you can define a less familiar construct in terms of a more familiar one. However, the "default" isn't quite the same as an "else", since "else" can't stand on its own. A "default" is more like an "if" that's always true. So the above code is equivalent to: given $given { print "about to check $first"; if $given =~ $first { ...; break } print "didn't match $first; let's try $next"; if $given =~ $next { ...; break } print "giving up"; if 1 { ...; break; } die "panic: shouldn't see this"; } We do need to rewrite the relationship table in the RFC to handle some of the tweaks and simplifications we've mentioned. The comparison of bare refs goes away. It wasn't terribly useful in the first place, since it only worked for scalar refs. (To match identities we'll need an explicit ".id" method in any event. We won't be relying on the default numify or stringify methods to produce unique representations.) [Update: Instead of an ".id" method, which would be unclear how to compare, there's a "=:=" operator for comparing identities. Though you can always compare two id's with the "===" operator.] I've rearranged the table to be applied in order, so that default interpretations come later. Also, the "Matching Code" column in the RFC gave alternatives that aren't resolved. In these cases I've chosen the "true" definition rather than the "exists" or "defined" definition. (Except for certain set manipulations with hashes, people really shouldn't be using the defined/undefined distinction to represent true and false, since both true and false are considered defined concepts in Perl.) Some of the table entries distinguish an array from a list. Arrays look like this:
Channel: Education
Tags: apocalypse larry perl perl6 wall
Rating: ( ratings) Views: 4 Comments: 0
