World: r3wp

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.

I think, Carl deside these thing by trying to figure out, what makes 
most sense for a new one to programming. Or trying to make a more 
humane less computer technical language.

(funny thing is that I keep forgetting this detail , and every few 
months I loose an hour trying to debug code until I remember ... 
hehe)

I also only use them as bitwise ops, but I don't remember tripping 
over it very often. I just always use ANY and ALL. NOT was probably 
designed to be friendly, rather than pure, and I do use it a lot.

John, yes, and also supporting things people expect when coming from 
other languages.

I come from languages that either have an explicit boolean type (Pascal-like) 
or act like REBOL (Lisp-like and Smalltalk-like).

C-like languages always trip me up - a mass of design flaws, the 
whole lot of them.

Well, but, in this case, C works better by discerning | and ||

The thing is, C needs to because it doesn't have proper boolean types, 
and REBOL doesn't need to because it has the logic! type.

Maybe AND, OR and XOR should only be bitwise, and then introduce 
&& and || (and maybe logical xor ^^, but just maybe).

REBOL needs to as well, since it (IF, UNLESS, EITHER, etc.) implements 
anything as logic, in fact.

We can do explicit conversions, and our code becomes easier to understand 
as a result.

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