Re: parsing of if else command

[Tim H. <tim...@un...>]

sorry, this mail went accidentally only to Ethan instead of the whole 
list in the first time.


Ethan A Merritt wrote:
 > On Monday 07 April 2008 15:13, Tim Hoffmann wrote:
 >> 3) if if else else - syntax error if the first condition fails (2nd 
else)
 >> 4) if if else - syntactically correct; depending on the condition 
else belongs to the first or second if!
 >>
 > I think the blocking has to come first, because without multi-line 
support
 > the syntax is crippled.
I'm not really familiar with the code. Maybe a hack for if blocking 
would be possible without too much effort, but then again new problems 
would araise if one ever wants to have real loops, because the command 
parsing is linear. When talking about blocking, IMHO a decision has to 
be made if control structures (if, while, for) should become an 
elementary part of gnuplot. If so, one should really think about the way 
of parsing. If not, I consider the following to be sufficient.

Blocking is desirable, but it's more than I proposed. I was just 
thinking of a fix for nesting types 3) and 4) which I could manage in a 
short time. For a real blocking I would have to have a deeper look in 
the source code. I don't have the time for this now (maybe in two months).

My proposal would make the following possible (commands can also be more 
than one):
if (test) \
     command1; \
     if (test2) \
     command2; \
     else \
     command3; \
     command4; \
else \
     command5;

There are only two disadvantages compared to blocking:
1) The continuation char. Do you mean this by crippled? Can there be 
problems because of limitations in length?
2) you can't leave out the first else. If you do, you'll end up like that:

if (test) \
     command1; \
     if (test2) \
     command2; \
     command4; \
     else \
         command5;

For really long commands, one could refer to your proposed solution with 
load. It should be mentioned in the documentation.

 > Alternatively one could fix 'load' so that it doesn't eat the rest of the
 > line. But I think that would be just as much work, for less gain.
Eating the rest of the line feels wrong. But you know the code and the 
reasons better than me.