>... to resemble iif(). Would anybody find this useful? Here's an example of what I mean, run this:
>

< SNIP >

Color me silly, but I'd rather do it differently, using a data-drive. Consider a table with two fields, ExpnToTest,HitResult, both large character fields:

FUNCTION MondoIIF
LPARAMETER tuValToCheck, tcConditionTable
LOCAL uReturn,  cCurrentAlias
cCurrentAlias = ALIAS()
SELECT 0
uReturn = NULL
IF FILE(tcConditionTable + '.DBF')
   USE (tcConditionTable) AGAIN ALIAS (SYS(2015))
   SCAN
      IF EVAL(ExpnToTest)
         uReturn = EVAL(HitResult)
         EXIT
      ENDIF
   ENDSCAN
   USE
ENDIF
IF ! EMPTY(cCurrentAlias)
   SELECT (cCurrentAlias)
ENDIF
RETURN uReturn

The field ExpnToTest would contain an expression that would evaluate against tuValToCheck, and HitResult would be an expression that would be evaluated and returned to the caller. If the "Mondo" IIF table referenced didn't exist, or no ExpnToTest evaluated to .T., a NULL would be returned. So for the example we looked at before, the table would look like:

ExpnToTest                    HitResult
tuValToCheck = 1              "1"
tuValToCheck = 2              "2"
tuValToCheck = 3              "3"
tuValToCheck = 42             "The answer to life, the universe, and everything"

The number of conditions you can test is unlimited for all intents and purposes. This isn't by any means a finished, polished mechanism, but it shows how the problem can be approached in a better fashion. For example, you might not want to have a separate file per condition set, so a table that contained condition sets could be references and the desired set extracted as needed. The remainder is left as an exercise for the reader (IOW, I'm being lazy...)