World: r3wp

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]

Ladislav, http://issue.cc/r3/1879is a bit complicated when you consider 
that "operator" is used in REBOL jargon only for infix operations.
Your request looks like 3 related tickets:

- Extend the INTERSECT, UNION and DIFFERENCE functions to include 
the current bitwise behavior of AND, OR and XOR, respectively.
- Make operators for those functions (maybe &, | and ^).

- Change AND, OR and XOR operators (and AND~, OR~ and XOR~ functions) 
bitwise behavior to conditional behavior.
Is this a reasonable assessment of your request?

Peter, your right about the set functions and blocks. We should mention 
that in the ticket and say explicitly that these would not be set 
functions when applied to integers and such. The problem is that 
we would need bitwise operations to apply to strings and binaries 
as well, and these functions already treat them like sets. So there's 
a bit of functionality overlap that we have to deal with or else 
something will be lost.

your -> you're

The goal of having less dictionary entries to remember, and having 
the ops be smart, is valid; but in this case I think the meaning 
of the set op funcs (e.g. difference, union, etc.) are *much* clearer. 
Yes, most of us see AND and OR and know what's going on (though it 
sometimes makes my brain stutter a bit when debugging, especially 
XOR :-).

Having the set operations not act like set operations for some datatypes 
is only a little confusing - not much worse than what we have now. 
Losing either the setwise or the bitwise operations for strings and 
binaries is a much bigger problem - we need both, in different circumstances.

Sorry, just binaries. Good, I was worried that they might have tried 
to implement bitwise operations on R3 strings, which (conceptually) 
don't have a bitwise definition.

Though bitwise operations are allowed on chars, so that's a little 
inconsistent.

I think that not allowing bitwise operations on strings is a pragmatic 
restriction, because the internal data might get corrupted by them, 
and at the very least the results would be different depending on 
which internal storage mode is used. I'm not sure whether bitwise 
operations on characters currently work correctly at all, for the 
same reasons. What would be the proper behavior, and how can we check?

OK, just checked, characters are operated on as if they are integers 
of the same numeric values; that will do. We can't implement this 
in string form because we don't support UCS4 internally.

Note: COMPLEMENT doesn't support char!, probably because it would 
always result in characters that string! doesn't support, or even 
Unicode in many cases. This would continue to be the case with this 
proposal.

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)