Re: Perl6 grammar (take V)
On Fri, 2002-07-12 at 02:33, Sean O'Rourke wrote:
> What's currently "supported":
> - if/elsif/else (even "unless" and the feared "elsunless";)
When we talked about this last, I had been concerned about loops and
conditionals, but others had scoping concerns. Ok, perhaps there's no
way we can roll in loops (though that seems wrong to me), but please
don't do THIS.
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. Could it be a better option if you added
whipped cream and a cherry?! This never gets as ugly as C because the
only tokens that can follow 'else' are 'if' 'unless' and '{'... no
ambiguity.
Now, for those who will freak out, you could preserve "elsif" as a
deprecated form, but I'd at least say that it should generate a
compatibility warning so that it's fair game for later removal.
An example:
$pid = fork() // -1;
if $pid < 0 {
# error ...
} else unless $pid {
# Parent
} else if $pid > 0 {
# Child
} else {
# Huh? Can't happen
}
Re: Perl6 grammar (take V)
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
Re: Perl6 grammar (take V)
At 11:33 PM -0700 7/11/02, Sean O'Rourke wrote: >It's time for my weekly post to this old thread. The grammar has >grown enough to deserve more than one file, and is starting to change >in new directions. For example, it's now Turing-complete, if you have >a Parrot engine and a bit of spare time. Call it a primitive "demo >version" of some of Perl 6's features. If nothing else, it will let >you start training your fingers to 'concatenate' _$like _$this. [snip] >The fact that I've been able to whip this up in a couple thousand >lines of code is a remarkable testament to Parrot's maturity, and to >the wealth of tools available in Perl 5. In particular, without The >Damian's Parse::RecDescent, Melvin Smith's IMCC, and Sarathy's >Data::Dumper, it never would have been possible. What, this actually *runs*? Oh, my. Can you get this suitably cleaned up for checkin to the parrot tree? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
