On Mon, 2002-05-06 at 12:22, [EMAIL PROTECTED] wrote:
> |Oh! I have an idea! Why don't we make the lexer just realize a prefix
> |"els" on any operator. Then you could do C<if .. {} elsexit>. :P
> |
> |My point is that, IMO, this whole "els" thing is completely preposterous.
> |I'm the kind of person that likes to keep down on keywords. And I never
> |liked Perl5's C<elsif> anyway; I always preferred C<else if>. I really
> |don't understand what at all is appealing about C<elsloop>.
>
> ]- yeah i think we better stay away from all those elsxxx nightmare ... and don't go
> to the trap of those or similar abbreviation ...
> Better have else xxx (whatever this xxx is)..
> i think we should do abbreviatoins only on something we use very often..
It's odd, folks are still talking about the icky elsstuff, but I never
saw any discussion of my BNF proposal. Was it that no one saw it, that
my BNF was too rusty, or the idea of abandoning elsif for (in
pseudo-ebnf)
FLOW =
((if|unless|while|for) (E|CLOSURE_ARGS) | loop [E;E;E])
BLOCK
[else
(FLOW|BLOCK)] ;
was discounted out of hand?
I'd really like to hear why something so almost absurdly simple could be
totally wrong. Heck, you could keep elsif around as a legacy if you
wanted, but it becomes rather pointless. Doesn't this make the grammar
shorter, and thus parsing more efficient as well?
Someone had questioned the value of my example, so let me cite another:
while $fh.getline -> $_ {
...
} else for @users -> $user {
send_mail $user, "Hello, $user, the file was empty";
} else if openlog $$, 'pid', 'user' {
syslog 'notice', "The file was empty!";
} else {
die "Cannot even invoke syslog... a bad day: $!";
}
This is a very clear chain of causality. I could re-write it with nested
ifs and the like, but here we see the very heart of what I was trying to
do, with very little waste.
