World: r3wp

Make operators for those functions (maybe &, | and ^).

 - that is not what I am suggesting. Somebody else could, but I do 
 not need infix operators for that.

Losing either the setwise or the bitwise operations for strings and 
binaries is a much bigger problem

 - I do not understand, how you can lose something you do not have?

OK, that is why I was suggesting a separate ticket. Do you mind a 
little rewording in the ticket, or splitting into more tickets, if 
the proposal stayes the same, semantically? This would allow us to 
make them more precise, and show competing proposals, some of which 
could be rejected in favor of others. The existing ticket seems like 
a summary of an AltME conversation, so it would be tricky for an 
implementor to follow.

We have bitwise operarions on binaries. They could be considered 
to be more important than the bitwise operations on integers in some 
cases.

We also have setwise operations on binaries. They are probably less 
important, but I'm sure some people would miss them.

My main concern is to make the text readable for the uninitiated. 
The text, if split into more tickets, loses meaning, and I would 
not understand why such proposals are there.

Of course, I can imagine that some alternative proposals to this 
may be as good or better than this one.

My main concern really is the fact, that REBOL is the only programming 
language I know not having conditional AND and OR.

(for the "strict" languages, which allow only logic! values to be 
conditional, the logic operators *are* conditional, for the non-strict 
languages, there is no problem either, since their AND and OR are 
conditional, only REBOL has chosen to not have conditional AND and 
OR)

Well, the setwise-vs-bitwise treatment of binaries is a real issue 
with the INTERSECT, UNION and DIFFERENCE functions, so one alternate 
proposal would be to use different function names for the bitwise 
functions/operators. This would allow one or the other proposal to 
be rejected. Also, the operators proposal would need to be seperate, 
so it could be separately rejected. We've done this with other competing 
proposals before, so it's established practice. Why don't I come 
up with a set of proposals and run them by you first?

Setwise treatment of binaries is a no-issue for me. I wonder, whether 
it really is an issue for somebody else.

But, as I said, my main concern is the "REBOL does not have conditional 
AND and OR", so, if you succeed to split it up in a way this still 
is obvious, I will be OK with it.

If it's not, then the INTERSECT, UNION and DIFFERENCE proposal could 
be accepted and the BIT-AND, BIT-OR and BIT-XOR proposal (or whatever 
you prefer as an alternate convention) could be rejected. Rejection 
of a proposal is not a problem in this case - rejection of *both* 
proposals is a problem.

Yes, I suggested the INTERSECT, etc. modification as a supporting 
matter to show how one can do without changing too much. I can imagine 
a lot of different alternatives, though.

in what context usually is it an issue not having "conditional" logic 
operators?
can u give some actual examples?

if condition and find data something [...]

for which case was the 'found? function been invented

I see it is the main purpose why the AND and OR operators are needed 
at all. We don't need them that much to yield logic values as we 
need them to yield condition values. My main argument is the comparison 
of NOT usage (which is conditional, and used a lot), versus the COMPLEMENT 
usage (which is nonconditional, compatible with AND and OR, yet used 
much less)

still have to convert the condition to-logic, i got that, but i got 
used to the any, because most of the cases we don't need to eval 
everything

Tamas, did you read the ticket? I do not want to repeat everything 
I wrote in there.

(would be impractical)

Yup, onetom. But mixing prefix and infix is awkward in REBOL, requiring 
a lot of parentheses. This makes REBOL code slower and uglier.

Ladislav: sorry, i was just following the chat here. will read the 
ticket.

FOUND? and TRUE? take time to execute, and often make it necessary 
to put code in parentheses, which also have overhead. Silly interpreted 
language stuff, but it's significant.

Actually, the case of TO-LOGIC, FOUND? and TRUE? shows what is bad 
about it. Does common user know which should be used?

They are not interchangeable!

(i don't really know.. never used true?.. looks a bit silly. i got 
used to the conditional meaning of stuff, so i hardly use AND/OR 
but ANY/ALL instead :)

I often use the prefix forms of AND, OR and XOR because of the parentheses 
issue. Operations used often, but not always the operators.

AND~, OR~ and XOR~ are the power-reboller's friend :)

A little comparison of TO-LOGIC, TRUE? and FOUND?:

>> to-logic 0
== false

>> true? 0
== true

>> found? 0
== true

>> to-logic false
== false

>> true? false
== false

>> found? false
== true

So, this state is not what could make an uninitiated user happy.

onetom ~/rebol $ grep -riw AND `find . -iname \*.r` | wc -l

i ran this for OR too and 95% of the occurances are in comments or 
strings and where it's found in the code, it's usually used as a 
bit-wise operator

(i have rebgui, cheyenne, vid-ext, rebdb, host-kit, musiclessonz, 
power-mezz, glass, r3 gui in this folder. ~500 files)

aha, fine, that is perfectly possible, but, it may be caused e.g. 
by the fact, that you actually are forced to use ANY and ALL for 
processing conditional values, since AND and OR are not working satisfactorily 
for that purpose

Ladislav: yes, probably that is the case; which for example i am 
completely happy with

I prefere ANY and ALL for this reason:

>> if (print 1 true) AND (print 2 false) AND (print 3 true) [print 
4]
1
2
3
== none

>> if all [(print 1 true) (print 2 false) (print 3 true)][print 4]
1
2
== none

It confused me a bit, what exactly was meant by "conditional AND 
and OR". So it's not just, that they operate on logic values, but 
that the second operand is only evaluated, if needed.

I presume, it'll be hard to implement conditional AND and OR in REBOL, 
because it's not just a type check as with other operators.

it's not just, that they operate on logic values, but that the second 
operand is only evaluated, if needed

 - actually, you missed the explanation. "Conditional" was coined 
 by Brian and was meant to represent functions able to yield values 
 usable as CONDITION arguments of IF etc. as well as being able to 
 combine conditional expressions into more complex conditional expressions 
 (which is not true for AND and OR as demonstrated)

no other property was mentioned

Aha, then we're back to my original understanding, and then I don't 
understand, why you say
REBOL does not have conditional AND and OR

REBOL does to some extend:

>> true and true
== true

Isn't that a conditional AND from your (or Brian's definition)?

no its a logical one.   it only compares logic!  datatypes correctly.

(within a conditiional minset)

true and 1
none or none

each operand could be a parameter for IF/EITHER/UNLESS and has it's 
very well defined logic! value

Yes, I understand, but wouldn't it possible confuse Carl to say "REBOL 
does not have conditional AND and OR". It does to some extend, right?

thats why i was asking for an explicite definition above

ok :)

I guess, there are several problems in this. Some conditions are 
dealt with by AND and OR, the logic! ones. But not all conditions, 
IF/EITHER/UNLESS can handle is supported by AND and OR. And second, 
AND evaluate all operands, even if some are false. That is the definition 
of "conditional AND and OR" I found from a search:

http://download.oracle.com/javase/tutorial/java/nutsandbolts/op2.html


See "The Conditional Operators" a bit down and the mention of "short-circuiting" 
behavior.

Not having the "short-circuiting" behaviour is a direct bug, as I 
see it. Because this code with create an error:

if (port <> none) and (data: read port) [ ... ]


But I have a gut feeling, that logic AND isn't very REBOLish, and 
that's why we more often use ALL and ANY. It's just a feeling, so 
feel free to disagree.