[Omake] Re: [CUCS Bug 545] "or" and "and" take each argument to be a _sequence_ of values.

[Aleksey Nogin]

On 26.06.2006 13:25, Jason Hickey wrote:

> Aleksey Nogin wrote:
> 
>> My model (1) is fairly simple and follows the "Boolean algebra" model 
>> as well. It goes as follows - the "and" operation takes a _list_ of 
>> arguments (_not_ list list) and each individual argument is converted 
>> to a boolean using the "strong and" interpretation (both empty values 
>> and arrays containing false are mapped to "false").
> 
> 
> But the identity of conjunction is "true", which just means that what 
> you have defined is not a conjunction.  This is the whole issue--do we 
> want to re-implement $(and) so that it is not a conjunction?

No, but the issue is that the normal conjunction is defined on 
_booleans_ and it is clear that

$(and e1, ..., e2)

should be the normal conjunction when all the expressions are proper 
booleans. Now the question is - when they are not - how do we convert 
arbitrary OMake values to booleans. Your answer:

split them along the whitespace, convert each piece to a boolean 
individually and them take a conjunction

is cute, but IMO _wrong_. In particular, it violates a critical (IMO) 
requirement, that the empty values should be mapped to "false".

Basically, I agree that it is very reasonable to require that

$(and e1, ..., en) evaluates to

f(e1) /\ f(e2) /\ ... /\ f(en)

for some "reasonable" f that maps OMake values to booleans (although the 
"two different calling conventions" is also a reasonable IMO, but 
different, approach).

You seem to assume that f _must_ split its argument into individual 
values and then do something algebraic on them. I claim exactly the 
opposite - that it is quite misleading to allow it to do so. f must 
analyze its argument _as a whole_ and return "false" whenever it is empty.

My whole argument is that it is very misleading to simply take this to 
be a question of picking an appropriate "bool list list -> bool" 
function for interpreting the $(and...). What we need it a "value list 
-> bool" and it is misleading to assume that the first step must be 
"List.map (fun v -> List.map bool_of_value (values_of_value v))". It is 
true that all the choices we are currently discussing can be expressed 
in terms of "bool list list -> bool", but it is also the case that 
something that looks very natural in the "value list -> bool" world may 
end up having a very unnaturally looking "bool list list -> bool" 
projection.

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal)
Office: Moore 04, tel: (626) 395-2200