Aaron Sherman wrote: > An example: > > $pid = fork() // -1; > if $pid < 0 { > # error ... > } else unless $pid { > # Parent > } else if $pid > 0 { > # Child > } else { > # Huh? Can't happen > }
Of course, your indentation implies a different syntax than the parser actually sees. The parser sees it more like this: $pid = fork() // -1; if $pid < 0 { # error ... } else unless $pid { # Parent } else if $pid > 0 { # Child } else { # Huh? Can't happen } Now, as you point out, the dangling-else ambiguity isn't a problem in Perl, since the curly braces are required. Nonetheless, _I_ want to keep the 'elsif' because it means that I and the parser are "seeing" the same thing. When my mental model of something doesn't match the way that thing really works, the opportunities for screwing up are dramatically increased. Now, I don't see _how_ I can screw it up in this case, but I also don't see any reason for gratuitously removing the ability have my mental model match the actual model. > There's really no good reason to continue treating conditionals this > way. A simple > > cond: ('if'|'unless') expr block [ 'else' (cond|block) ] > > solves the whole thing; is easy to write and parse; and reduces the > number of keywords in Perl. Why does it matter how many keywords there are in Perl? I thought that a major motivation for having the sigils was that it makes language extension easier, since variables are effectively in a different namespace than keywords. The only downside I can see in having the extra keyword is that it makes it problematic *if* I want to name a subroutine "elsif". And I *don't* want to. :-) =thom