On Sun, Mar 12, 2017 at 10:24 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > One point here is that we need to distinguish problems in the expression, > which could arise from changing variable values, from some other types of > mistakes like \elif with no preceding \if. When you see something like > that you pretty much have to treat it as a no-op; but I don't think that's > a problem for scripting usage. > One of my discarded write-ups from last night made a point that we don't really distinguish between run-time and compile-time errors - possibly because we haven't had to until now. If we detect what would be considered a compile-time error (\elif after \else for instance) we could treat anything that isn't a conditional meta-command as a no-op with a warning (and exit in stop-script mode). 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 Yes, that's wordy, but if that was shown the user would be able to recognize their situation and be able to get back to their desired state. Figuring out what the valid correction commands are for each invalid state, and where the user is left, is tedious but mechanical. So we'd need an INVALID state as well as the existing IGNORE state. \endif would always work - but take you up one nesting level The user shouldn't need to memorize the invalid state rules. While we could document them and point the reader there having them inline seems preferable. > > We could imagine resolving this tension by treating failed \if expressions > differently in interactive and noninteractive cases. But I fear that cure > would be worse than the disease. > I don't think this becomes necessary - we should distinguish the error types the same in both modes.
