Re: parsing of if else command

[Ethan A M. <merritt@u.washington.edu>]

On Monday 07 April 2008 15:13, Tim Hoffmann wrote:
> Hello,
> 
> because of a recent discussion on comp.graphics.apps.gnuplot I realized 
> that the parsing of if ... else ... is somewhat "unusual". If the 
> condition fails, gnuplot will jump to the next else (as documented). I 
> don't consider this to be a good solution, because this causes troubles 
> in nested if else statements.

I think the biggest problem with gnuplot's if/else implementation is
that it is limited to a single line.  The following simple construct,
if it were possible, would make the whole thing a lot more usable:
   if (test) load 'option1'; else load 'option2';
The files 'option1' and 'option2' could hold arbitrarily complex
code, partially making up for the lack of block structure.
But this doesn't work, because the command 'load' destroys the rest of
the line.  Since an 'else' clase must be on the same line, but the
line is lost, you can have no 'else' clause after a 'load' command.

So I suggest that the first step should be extending the syntax to
allow multi-line constructs.  Here is one possibility:

if (test) begin
   ...
   ...
else begin
   ...
   ...
endif


The 'begin' and 'endif' are not needed if the command remains on a single
line, so backwards compatibility is maintained.

 
> A short summary on the possible nestings (more detailed in the newsgroup):
> 1) if if - OK
> 2) if else if else - OK
> 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!
> 
> Looking at the code, I think it should be easy to switch from this 
> evaluation to a stack-like interpretation which allows above nestings 
> and is furthermore the "natural" way of blocking in programming 
> languages. It involves only counting if else pairs and resuming 
> execution at the right level instead of simply the next else. I will 
> have a try with this in some days.
> 
> The only thing left for a perfect if would then be some blocking to make
> if (if ...) else possible. But I leave this for the moment, firstly 
> because it appears to be more involved to insert additional tokens () or 
> maybe {}, and secondly because you can archive the same logic by if else 
> if ... and negating the first condition.

I think the blocking has to come first, because without multi-line support
the syntax is crippled.

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.
 
> Comments are welcome.
> 
> Regards,
> Tim

-- 
Ethan A Merritt