"David G. Johnston" <david.g.johnston@gmail.com> writes:
> There are only four commands and a finite number of usage permutations.
> Enumerating and figuring out the proper behavior for each should be done.
> Thus - If the expressions are bad they are considered false but the block
> is created
> If the flow-control command is bad the system will tell the user why and
> how to get back to a valid state - the entire machine state goes INVALID
> until a corrective command is encountered.
> For instance:
> \if
> \else
> \elif
> warning: elif block cannot occur directly within an \else block. either
> start a new \if, \endif the current scope, or type \else to continue
> entering commands into the existing else block. no expression evaluation
> has occurred.
> \echo 'c'
> warning: command ignored in broken \if block scope - see prior correction
> options
This is looking a whole lot like the overcomplicated error reporting that
we already considered and rejected. I think it's sufficient to print
something like "\elif is not allowed to follow \else; command ignored"
and not change state. We're not really helping anybody by going into
an "invalid machine state" AFAICS, and having such a thing complicates
the mental model more than I'd like.
A different way of looking at this problem, which will seem like overkill
right now but would absolutely not be once you consider looping, is that
what should happen when we see \if is that we do nothing but absorb text
until we see the matching \endif. At that point we could bitch and throw
everything away if, say, there's \elif after \else, or anything else you
want to regard as a "compile time error". Otherwise we start execution,
and from there on it probably has to behave as we've been discussing.
But this'd be pretty unfriendly from an interactive standpoint, and I'm
not really convinced that it makes for significantly better error
reporting.
regards, tom lane
