On Fri, Apr 27, 2012 at 12:55:06PM -0400, Eric Brine wrote:
> On Fri, Apr 27, 2012 at 3:49 AM, Eric Brine <ikegami@adaelis.com> wrote:
>
> > On Thu, Apr 26, 2012 at 10:07 PM, David Nicol <davidnicol@gmail.com>wrote:
> >
> >> So it appears that the answer is, we can't have functional "if"
> >> without either switching from a bison grammar with single-token
> >> lookahead to a more complicated state machine framework with a stack
> >> and arbitrarily long lookahead, to allow looking past the
> >> parenthesized condition
> >
> >
> > Still not good enough.
> >
> > if ($c) { $x } else { $y } / ...
> >
> > Is that an "if" statement before a match operator or an "if" expression
> > before a division operator?
> >
>
> One could say this is more of a problem with "/" than with "if" expression,
> and it can be be resolved as follows:
>
> if ($c) { $x } else { $y } / ... # "if" statement + match
> +if ($c) { $x } else { $y } / ... # "if" expression in diviision
>
> Which brings me to my point. Would it be bad if "if" expression always
> required leading "+" (last statement of sub or block excepted, of course)?
> Concise existing mechanism providing visual cue of meaning. It has it all.
It's not just with "/". Consider this:
sub foo {
if (1) {bar()} else {baz()}
-$something;
}
This currently returns '-$something', but if there is an expression
variant of if(), it will return 'baz() - $something'.
If only we could go back in time, and require ';' as statement terminators,
even on compound statements.
Abigail
Thread Previous
|
Thread Next