Problematic @(if)/@(elif)/@(else)/@(end).

 new new list compose Reply to this message Top page
Attachments:
+ (text/plain)
+ (text/html)

Delete this message
Author: Kaz Kylheku
Date:  
To: TXR Users
Subject: Problematic @(if)/@(elif)/@(else)/@(end).

Hi all,

I don't like how @(if) works as a syntactic sugar for a @(cases) with @(require) clauses. It is confusing because it doesn't behave like a nested if in other languages.

Here is a synopsis of the problem:

Consider:

@(if C1)
X
@(elif C2)
Y
@(end)

Suppose that both conditions C1 and C2 are true. Then block X will be evaluated. Now suppose that X triggers a failure. Oops; because of the way this is defined, the pattern matcher will end up in Y. This is because the failed case triggers the next case: it's just the @(cases) construct in disguise. It falls through C2, which is true.

Worse, C2 could be initially false, but made true by logic in X.  And, worse still, an @(else) clause is always evaluated if any of the previous ones fail anywhere, not only on their conditions.

It would be better for @(if) to have the intuitive semantics: select the first clause for which the condition is true, and then remove any subsequent clauses from consideration.

That is to say, if the pattern-matcher descends into X above, there should be no possibility of condition C2 being evaluated and then Y.  If X fails, then the @(if) fails.

If I make this change, it will be subject to the backwards-compatibility -C option, of course. I may also make the old behavior continue to be available under some other operator name, like if* or whatever.