Discussion:
A2P4: if, else if, else...
(too old to reply)
Brian Keng
2004-06-27 20:24:49 UTC
Permalink
Hi,

I'm having a problem with this sequence of tokens:

if expr then block_statement else if expr then block_statement else if
expr then block_statement endif; endif;

can be interpreted in two ways:

if expr then
block_statement
else if expr then
block_statement
else
if expr then
block_statement
endif;
endif;

or

if expr then
block_statement
else
if expr then
block_statement
else if expr then
block_statement
endif;
endif;

Now I think these both ways produce the same logic, but they definitely
get expanded in two ways. Firstly, which way should they be expanded?
Secondly, how do we specify a CFG to do that?

I'm been working on this problem for a long time and haven't come up
with a solution. We talked about Java's dangling "if" in class but we
didn't really write a CFG for it, as far as I know we haven't talked
about anything similar to this problem. I found a website on the
dangling else (http://www.parsifalsoft.com/ifelse.html) but it's not
exactly the same problem (but I think it's similar). I think it has
something to do with "else if".

So, can we get a few hints about how to go about handling this problem?
I'm guessing we're not allowed to write a ambiguous grammar (and let
CUP shift for us). If I'm missing anything blatantly obivous, please
let me know.

Thanks,
Brian Keng
Andrew Craik
2004-06-27 21:30:49 UTC
Permalink
Hey,

There of course is a third option in this problem, that being that the
statement you provided is malformed. The condition statement in the SL spec
says the following:

"An else if clause consists of the keywords else and if, followed by an
expression of boolean type, followed by the keyword then, followed by a
block statement.
An else clause consists of the keywords else followed by a block statement."

Now a third way of interpreting this (which is the way I interpreted it) is
that an else keyword immediately followed by an if keyword is an else if
always, ie you cannot create an else block that contains only an if
statement. That is to say the following is illegal in my interpretation
(too many endifs...):

if expr then
block stuff
else
if expr then
block stuff
endif;
endif;

The same idea could be conveyed by the following structure:

if expr then
block stuff
else if expr then
block stuff
endif;

Yet the following is legal in my interpretation (as the else and if keywords
are seperated by other tokens):

if expr then
block stuff
else
block stuff (not an if statement)
if expr then
block stuff
endif;
endif;

My interpretation of the spec was based on the statement that and else if is
an else token followed by an if token. Your interpretations would seem to
violate this definition, but that is in my biased opinion, perhaps we could
have some official guidance on this topic...

Andrew
Post by Brian Keng
Hi,
if expr then block_statement else if expr then block_statement else if
expr then block_statement endif; endif;
if expr then
block_statement
else if expr then
block_statement
else
if expr then
block_statement
endif;
endif;
or
if expr then
block_statement
else
if expr then
block_statement
else if expr then
block_statement
endif;
endif;
Now I think these both ways produce the same logic, but they definitely
get expanded in two ways. Firstly, which way should they be expanded?
Secondly, how do we specify a CFG to do that?
I'm been working on this problem for a long time and haven't come up
with a solution. We talked about Java's dangling "if" in class but we
didn't really write a CFG for it, as far as I know we haven't talked
about anything similar to this problem. I found a website on the
dangling else (http://www.parsifalsoft.com/ifelse.html) but it's not
exactly the same problem (but I think it's similar). I think it has
something to do with "else if".
So, can we get a few hints about how to go about handling this problem?
I'm guessing we're not allowed to write a ambiguous grammar (and let
CUP shift for us). If I'm missing anything blatantly obivous, please
let me know.
Thanks,
Brian Keng
Loading...