World: r3wp

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)

So, no new operators.

and in fact XOR is the infamous ALTER.

Sorry Max, not at all.

ALTER is a modifying function.

yeah... tought about it and I was going to say... forget it.

modifying or not, its not doing the same thing anyways.

so I guess we only have to find an new function name for XOR's bitwise 
variant?

DIFFERENCE

ah, sorry, it would need to be the COMPLEMENT DIFFERENCE

or not, I confused it.

no it seems to work perfectly.  I just tried it.

(on blocks at least)

>> a: [1 2 3 4] b: [1 2 3 5]
== [1 2 3 5]
>> difference a b
== [4 5]

is exacty what I would expect of XOR on blocks.

>> difference make typeset! [none! unset! integer!] make typeset! 
[decimal! inte
ger! tuple!]
== make typeset! [unset! none! decimal! tuple!]


>> xor~ make typeset! [none! unset! integer!] make typeset! [decimal! 
integer! t
uple!]
== make typeset! [unset! none! decimal! tuple!]

So, yes, it should be DIFFERENCE

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.

Agreed, this is key

I feel a little confused. Are you proposing that DIFFERENCE be used 
for bitwise XOR?

So logically:

>> (#"^(40)" xor #"^(C0)") = (difference #"^(40)" #"^(C0)")

I like the type adaptivity of REBOL and I build on it in all of my 
code, but in this case....


we have two completely different operations which can use the same 
datatypes in different ways... so there is no way to consolidate 
them.  hence this whole discussion

Are you proposing that DIFFERENCE be used for bitwise XOR?
 - I already wrote the ticket for it: http://issue.cc/r3/1879

But, unless you understand the difference between the conditional 
(NOT) and nonconditional (COMPLEMENT) operators, it is hard for you 
to find out what is going on.

the whole bitwise thing is pretty fucked up anyway. i tried to do 
a disk editor, a pic microcontroller HEX file processor, a custom 
serial communication protocol and in all cases i had to ping-pong 
between binary! issue! integer! and had to trim to the right bit/byte 
counts. it was a nightmare all the time.

it's big grief for me because rebol could be the bridge for hardware 
guys to the modern, internet connected world

no processing.org and arduino "C" crap..

now u want to apply set theory operation names to bitwise logic?

Yes, Tamas, it might be a good idea to suggest some improvements, 
if you are inclined to. You just need to realize, that there already 
are differences between the behaviour of R2 and R3.

:-)

it sounds very impractical to me...

sounds very impractical

 - well, my suggestion was based on the fact, that the UNION already 
 works as OR in many cases anyway.

As an example, see the comparison of XOR and DIFFERENCE above.

Ladislav: im back to the Rebol world since my new job allows me to 
use it. if i can secure my position in the next few month, i definitely 
will make exact suggestions

Of course, an alternative to use a completely different set of names 
can be considered as well.

Actually, I use bitiwse  XOR and OR to perform arithmetic on characters 
in my string encoding utilities script.

although having the set functions support the bitwise ops like they 
should...

I *also*I want bitwise infix ops... as long as the set functions 
to do the same arithmetic... basically just like how  'ADD  and  
'+  are equivalent.

If the broader problem would turn out to be unsolvable in the REBOL 
dialect, there will still be an R3 extension with a Red/System dialect

So, if I understand correctly, I would write someting like:

iso-ch: union #"^(40) utf-ch-2

and 

utf-ch: rejoin [#"^{C3}" difference #"^(40)" iso-ch]

- that is one possibility

It does look a little unusual but probably the equivalents with OR 
and XOR look odd to other people.

It's a long time since I studied set theory but if I remember correctly, 
the union of two sets is not dependant upon the order of the elements 
in a set.


So shouldn't the UNION of two sets of bits really be one of three 
values {0}. {1} or {0,1}.


I know this is knitpicking but I'm very used to XOR being bitwise.

Union appears to be implemented so in R3:

>> union [ 0 0 0 0 1 0 0 0] [ 0 0 0 1 0 0 0 0 ]
== [0 1]