World: r3wp

OR AND etc, already return errors when you try to compare incompatible 
datatypes.  right now it seems very odd to me that #[none] is not 
comparable to logic values.


none is part of the logic! handling in conditionals and loops... 
IMHO it should be in logic ops and funcs too.

There are many funny things. Also why is there a TRUE? function but 
not a FALSE? function?

FALSE? function is NOT

any [none none]  is the none! aware version of ORing :)

i don't like infix much anyway

onetome... but its not an op   :-)

Yes, FALSE? is NOT, but then why do we have TRUE? There's no need 
for it, right? You can just ask on the operation, you're doing.

Yes, but just recently, a user had to choose between:

    any reduce [expr1 expr2]

or 

    (true? expr1) or (true? expr2)

, which are equivalent for him, but not nice.

if some-func OR other-func [] would be nice to support... though 
I ALWAYS use any/all... its become a habit  :-)

he could not use

    any [expr1 expr2]

, since he wanted EXPR2 evaluated.

Ah, and OR is binary OR, when used on integers, which justify TRUE?. 
:-) Still funny.

I guess, that it is more annoying than funny.

Geomol, TRUE? makes any "truthy" value and acutal #[ true ] value. 
  
which, as Lad just showed, is compatible with logic ops

its the newer name of  FOUND?  ;-)

I also prefer any [ ... ] instead of OR. I almost never us OR. But 
I always use infix operators in math, and I very rarely use ADD, 
SUBTRACT, etc.

Yeah, so TRUE? is kinda ok, but I would expect FALSE? to be there 
too then, to make it complete.

Geomol, in R3 we have: 
>> false? true
** Script error: false? has no value

>> true? true
== true

same here.. for some reason. but i miss the infinite arity of lisp 
for add, max, min

yeah, we should have block versions of the various math ops as standard 
in the language.  
 similar to any/all for conditionals.

something like:
sum [ 1 2 3 4 5 6 ]
min/max-of [ 1 2 3 4 5 6 ]
etc.

42 * [1 2 3 4]

[a b c d]: 42 * [1 2 3 4]

maybe too unreadable. :-)

its the newer name of  FOUND?
 - Max, that is an error. see this:

found? false ; == true
true? false ; == false

TRUE? is the "IF compatibility function"

If you want FALSE? just define:

    false?: :not

yes

Does anyone see any problem if logic ops support none! values? If 
not, go ahead and suggest it Ladislav.

It is not about supporting #[none!], it is more about not supporting 
other operations, that aren't logic-like

you don't want AND/OR to support   bitwise ops?

e.g. typeset or typeset is actually a union for me, and therefore 
should be performed using the UNION function preferably

you don't want AND/OR to support bitwise ops?
 - they are logic-incompatible

(in REBOL)

because 0 can be used to represent TRUE in REBOL, not FALSE

I expect   true == (0 AND 0)   if that is what you mean.

but I think I understand the deeper question you are hinting at.


AND/OR actually are two completely different ops rolled into the 
same wrapper.


on one part they act like a logical comparisons, on the other hand, 
they *also* act as a "bitwise" operators.  

because of this we cannot compare data *with* logical! or none! values.


I would gladly separate both as two sets of ops.   && ||  symbols 
come to mind to use as "bitwise" ops.  

I'd keep AND/OR as logical operations *only* allowing us to compare 
any data as logic comparisons.

AND/OR actually are two completely different ops rolled into the 
same wrapper

 - yes, that is the problem. I would even add, that not just two... 
 Such a setup *might* work, if the ranges were disjoint. But, in REBOL, 
 they are not disjoint, because any value can be used as logic by 
 IF.

yes exactly.   I agree completely now, that I understand the point 
fully.

I am glad I asked here before writing something in CC, since now 
I know better how to make my arguments more convincing.

I think my post above gives a good clear starting point for the CC 
ticket.

To complete the informations, I should probably perform a user poll 
in here. So, here goes:


*For me, one of the main goal of logic operators like NOT, AND, OR, 
XOR is to yield a value, that is used mainly as the CONDITION argument 
of the IF, UNLESS, EITHER, etc. control functions.


*Taking NOT (which is a unary logic operator) as an example, we see, 
that it is compatible with the above mentioned main purpose. The 
goal is achieved by "delegating" other functionalities NOT does not 
perform to COMPLEMENT. It is not possible for NOT to be both compatible 
with IF and perform the operations COMPLEMENT does.


*Taking OR (which is a binary logic operator) as an example, we see, 
that it is incompatible with the above mentioned main purpose, not 
being able to correctly handle some logic combinations, that would 
be compatible with IF. As an example, see the expression
    0 or true

, which cannot be used to yield an argument for IF, although both 
its arguments *are* compatible with IF. Interestingly, there is not 
a shortage of functions that are meant to perform analogical non-logic 
operations. I would like to specifically mention the UNION function, 
which seems to be related to OR similarly as COMPLEMENT is related 
to NOT.

*The question I am asking you is:

- Do you prefer the "logical" solution used in the case of NOT, and 
apply it to other operators like AND and OR as well, or

- Do you prefer the "non-logical" solution used in case of AND and 
OR and apply it to the NOT operator as well, or
- Do you prefer to keep the current state of affairs for R3?

I am for the first alternative, letting AND, OR and XOR work as "logic" 
operators only, "delegating" other (similar) functionalities to functions 
like UNION, INTERSECT, etc.

+ 1

I misunderstood as well. Thanks for clarifying.

+1 for having AND, OR, and XOR work as logic ops only.

I can see, how it became this way trying to avoid &, | and ^ for 
AND, OR and XOR.

The main reason the logic operators don't support none is to cut 
down on none propagation. We want those errors triggered, not unintentionally 
ignored.

So, which variant do you prefer?

I don't mind AND, OR and XOR being both logical and bitwise ops. 
If there is a problem with the current behavior, I don't remember 
being tripped up by it.

There surely is a problem, why would NOT be implemented differently 
otherwise?

Atm. I prefer the same as you too (the first one), but I would suggest 
some names for the bitwise and, or and xor in the reporting of this.

I feel, the language would benefit from being a bit more strict.

I'm tripped by it EVERYTIME I try to use them... none is a valid 
value for all logic control funcs.


so in over 10 years of reboling I've never been able to use them 
to control logic flow... I've used them only as bitwise ops...

Yes, Max, I guess, that you are not an exception

NOT is an action that generates a logic! value. I like the current 
Lisp-like treatment, having none and false being falsey values and 
everything else being truthy values, with explicit conversions already 
available if we need them. Whatever we do, please don't have zero 
values be false without explicit conversion.