r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Ladislav
20-Apr-2011
[8162x4]
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)
BrianH
20-Apr-2011
[8166]
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?
Ladislav
20-Apr-2011
[8167x2]
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.
BrianH
20-Apr-2011
[8169]
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.
Ladislav
20-Apr-2011
[8170]
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.
onetom
20-Apr-2011
[8171]
in what context usually is it an issue not having "conditional" logic 
operators?
can u give some actual examples?
BrianH
20-Apr-2011
[8172]
if condition and find data something [...]
onetom
20-Apr-2011
[8173]
for which case was the 'found? function been invented
Ladislav
20-Apr-2011
[8174]
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)
onetom
20-Apr-2011
[8175]
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
Ladislav
20-Apr-2011
[8176x2]
Tamas, did you read the ticket? I do not want to repeat everything 
I wrote in there.
(would be impractical)
BrianH
20-Apr-2011
[8178]
Yup, onetom. But mixing prefix and infix is awkward in REBOL, requiring 
a lot of parentheses. This makes REBOL code slower and uglier.
onetom
20-Apr-2011
[8179]
Ladislav: sorry, i was just following the chat here. will read the 
ticket.
BrianH
20-Apr-2011
[8180]
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.
Ladislav
20-Apr-2011
[8181x2]
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!
onetom
20-Apr-2011
[8183]
(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 :)
BrianH
20-Apr-2011
[8184x2]
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 :)
Ladislav
20-Apr-2011
[8186x2]
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
20-Apr-2011
[8188x2]
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)
Ladislav
20-Apr-2011
[8190]
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
onetom
20-Apr-2011
[8191]
Ladislav: yes, probably that is the case; which for example i am 
completely happy with
Oldes
21-Apr-2011
[8192]
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
Geomol
21-Apr-2011
[8193x2]
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.
Ladislav
21-Apr-2011
[8195x2]
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
Geomol
21-Apr-2011
[8197]
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)?
Maxim
21-Apr-2011
[8198x2]
no its a logical one.   it only compares logic!  datatypes correctly.
(within a conditiional minset)
onetom
21-Apr-2011
[8200x2]
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
Geomol
21-Apr-2011
[8202]
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?
onetom
21-Apr-2011
[8203]
thats why i was asking for an explicite definition above
Geomol
21-Apr-2011
[8204x3]
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.
onetom
21-Apr-2011
[8207]
yeah, i had the same feeling that it can be interpreted as the description 
of a non-complete boolean evaluation  (that was the name of the flag 
in turbo pascal ;)
Geomol
21-Apr-2011
[8208]
with -> will
onetom
21-Apr-2011
[8209x3]
the original problem was not AND/OR but NOT
so IF NOT is not the same as UNLESS
(if im correct)