World: r3wp

but brian, we cannot use AND/OR for logic comparisons...  #[none] 
breaks them and none *IS* a valid conditional value.

&& and ||  -- Please NOOOOOOOOO!

:-D

:-)

Yeah, they're ugly!

well, then we should remove   / * - + ^ too.

:-)

Just vote on Ladislav's proposal, and we'll see where the results 
lead.

But if almost nobody use OR today as logical or, but do as bitwise 
or, then we shouldn't change that.

LOR, LAND and LXOR
;p

If our goal is not to break things, yes. If our goal is to clean 
things up for the long term, now is the time.

None is a falsey value (NOT the value returns true), but not a false 
value. If we want to have AND, OR and XOR accept none as a false 
value, this will lead to errors being ignored unintentionally. We 
can do it, but there is a drawback. Still, I prefer that to making 
a separate set of operators for bitwise operations.

Some languages do that, but usually the other way around (bit-and, 
bit-or, ...).

How would you split OR into two, Gregg?

I find that R3 is the right time to address these issues in the language.


R3 is already incompatible.  I don't see a reason not to clean this 
up.

John: O and R. ;-)

It's funny, though, talking about logic values and then having "falsey" 
and "truthy" values.

So it'll go like: Hey Carl, we've found this huge problem ... and 
we have no solution.

Poor Carl.

I always use AND, OR and XOR in both their logical and bitwise sense. 
There is no confusion because I have to use logic! values for the 
logical behavior. This means that explicit conversions resolve the 
difference visibly.

but brian, the current AND/OR/XOR  *cannot* be used for logical ops. 
 the fact that none isnt' supported is the proof that its not working. 
  bitwise ops already exist in principle with the "set" functions 
 'complement, 'union etc.

Bitwise ops are computerish, logical ops are how humans think. I 
don't mind making the bitwise alternatives a little more verbose, 
or even adding a dialected BITWISE function.

I use the term "conditional expressions" for the truthy/falsey expressions, 
and "logical expressions" for the logic!-only ones, not interchangeably.

But, as Max brought up again, teh set ops are already there.

Ah, I see Brian. I'll try to remember that.

TRUE? was designed to convert a conditional expression to a logical 
expression. I think it used to say that in its docstring.

Anyway, vote on Ladislav's proposal. I'm a +1.

but in real life 'TRUE? is ugly, it makes code hard to understand 
and it forces us to use parens everywhere.... oh and it slows down 
code too.

sorry, but I can't fathom this:
if ((true? value) AND (true? value2)) OR (true? value3) []

this is how it should be:
if value AND value2 OR value3 []

(I'll shut up now  ;-)

There are similar conversions from is-it-zero-or-not to logical, 
from is-it-found-or-not to logical, from is-it-empty-or-not to logical. 
The conditional one isn't different. It is interesting that we don't 
have conditional AND, OR and XOR, but not really bad because of all 
the methods of explicitly converting to logical.

Brian, is it an intention, that you don't mention NOT?

NOT is conditional in REBOL, so it doesn't have the same constraints 
as AND, OR and XOR which are logical or bitwise, depending on the 
types of their arguments.

that's an unary logic! op!; hence a black sheep :)

Nice one, Tamas!

If you want to make logical versions of AND, OR and XOR separate 
from their bitwise versions, that doesn't make any sense - their 
types already distinguish them. If you want to change AND, OR and 
XOR to be contitional, then the additional ops can behave like the 
current ops behavior: bitwise or logical, depending on argument types.

contitional -> conditional

OK, reading the Brian's formulations, a different expression of the 
poll question might be: "Do you, REBOL users, want to have 'combined' 
logic and bitwise' binary operators, wouldn't you prefer the operators 
to be conditional?"

(NOT could also be bitwise; if u ask a hardware guy...)

Sure, but that is not the question here, the question should be what 
do you prefer.

If they are conditional (it would have to be including NOT), then 
the additional bitwise operators would be able to treat logic! values 
as if they were one bit.

onetom, we already have the bitwise not... its called complement 
 :-)

I would use the weird characters for the bitwise ops and the words 
for the logical ops. Maybe we could have ! be the same as COMPLEMENT 
instead of NOT.

words for the conditional ops, I mean

understood

brian, logic values IMHO should be "all on" or "all off", which is 
what I'd prefer, its also more complementary,  as in 

not value or this-one

what'd you think?

I mean, NOT would be the conditional not, and COMPLEMENT is the bitwise/logical 
not, same as now.

What if we write a C dialect in REBOL, and confine all support for 
[! | & || &&  >> <<] ops to that? ;-)

Logic and conditional values are all-or-not. Only bitwise is partial. 
For the one-bit logic! values, there's no difference.

I would probably vote for Ladislav's proposal if I knew which words 
were to be used for logical AND,OR etc. and which wold be used for 
bitwise.


For me, there is a clear advantage of additional clarity gained with 
separate  functions. I am not clear on the disadvantages (if any) 
of keeping them as single functions.

less words to learn and search in the dictionary.

the whole type system tries to build on this principle, so words 
can behave according to their context, just like in natural languages.

Peter, you may not have noticed, but I proposed all of the NOT, AND, 
and OR operators to be conditional. Their non-conditional counterparts 
already exist, and can be used for all the other purposes: COMPLEMENT 
(already not needing any change at all), INTERSECT (would need to 
add datatypes like LOGIC!, INTEGER!, CHAR!, TUPLE!, ...) and UNION 
(would need to add the datatypes like INTERSECT)