> -----Original Message----- > From: Luke Palmer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 3:11 PM > To: Austin Hastings > Cc: Michael Lazzaro; [EMAIL PROTECTED] > Subject: Re: Control flow variables > > > Austin Hastings writes: > > > > > > > -----Original Message----- > > > From: Michael Lazzaro [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, November 18, 2003 2:06 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Control flow variables > > > > > > > > > > > > On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote: > > > > Given that we've introduced the concept of "if" having a > return status: > > > > > > > > my $result = if ($a) { $a } else { $b }; > > > > > > > > > > Would that then imply that > > > > > > sub blah { > > > ... # 1 > > > return if $a; # 2 > > > ... # 3 > > > } > > > > > > ...would return $a if $a was true, and fall through to (3) if it was > > > false? > > > > > > > It sure should, provided there were a correct context waiting, > which would > > quite nicely address another WIBNI thread a couple of months > back about a > > quick return under those conditions. > > I.... don't think so. I say that all the time to mean precisely: > > if $a { return } > > And I don't think people are ready to give that up. > > In particular, if we kept our bottom-up parser around, this particular > construct would cause an infinite-lookahead problem. So for ambiguity's > sake, C<if $a> should not be a valid term without a block following. >
How on earth are you going to have an infinite lookahead problem when a semicolon is the next character? =Austin
