On Mon, 26 Aug 2002, Daniel Engovatov wrote:
> 2. "and" and "or", "n-of" functions. I think they are unnecessary in
> contrast to their "ordered-*" counterparts. Since we are now
> paying explicit attention to ERROR when evaluating policy, I think we
> should just go with the "ordered" versions of these functions for
> explicitly determinate results.
>
> Agree on "and" and "or" - should just leave ordered ones (or, rather,
> rename them to be "and" and "or"
>
> "n-of" is a different thing - does not have an alternative - and does
> not suffer from the current "or"/"and" indeterminate result - due to
> indeterminate evaluation order - issue..
>It certainly does. There is nothing to say in the "n-of" case that
>stipulates that the arguments need to be evaluated in first to last order.
>For example, they can be evaluated from last to first, which when taking
>into account for ERROR alters the evaluation.
Hm.. It was then lost by s at some point.
We may want to keep current "or" and "and" and "n-of" is we specify that
they treat ERROR arguments same as "false" (absorb errors).. So that they
never return ERROR. Kinda error catching function - you may use them to
wrap other predicates if you want to never return ERROR.
For example (or (integer-greater (integer-divide 1 0) 5)) will not return
ERROR ever, unlike just using "greater"
Then "ordered-" versions will specify that the ERROR is returned if
an argument of ERROR value is encountered, as it is specified now...
Daniel.
