On Wed, 2002-05-01 at 08:27, Miko O'Sullivan wrote:
> Damian said:
> > 6. C<otherwise> would seem to fit the bill rather nicely.
>
>
> To me, "otherwise" is a synonym for "else", and that makes it too
> confusingly similar. I foresee forever explaining to people the difference
> between C<else> and C<otherwise>. I'm not sure if C<otherwise> is popular
> because it is similar to C<else>, but I think the similarity is a reason
> *not* to use it.
>
> How about C<noloop>? It's absolutely clear what it means and won't be
> confused with "else".
Call it "maxheadroom" for all it will matter.
* people will still see conditional execution associated with loops
* the unless/elsif syntax is still grotesque and asymmetric
* the treatment of conditionals{1} vs conditionals{1,} is asymmetric
If you un-peel this and expose the elegant simplicity of flow control,
you can unify all of these concepts to their basic form:
flowcontrol:
controlblock |
controlblock TOK_else flowcontrol |
controlblock TOK_else block
;
controlblock:
controlword expression closure |
controlword expression block |
TOK_loop block |
TOK_loop expression ';' expression ';' expression block
;
controlword:
TOK_if |
TOK_unless |
TOK_while |
TOK_until |
TOK_for |
TOK_when
;
block: '{' statements '}' ;
closure: mumble... ;
expression: mumble... ;
statements: mumble... ;
I haven't really thought about this representation of the grammar much,
and I'm not grammar constructor by nature, but you can see the idea
here, and the stark simplicity of it.
What is so lovely about "elsif" that we cling to it, and mutate the
admittedly "obvious" choices elsewhere to preserve it?
