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
