Deprecate $ as bitwise exclusive or to free ascii-char $ for more useful purpose

[davidavdav]

As I tried to discuss here I believe that $ is a waste of single ascii character operator space. xor() would probably read just as easy. (Unfortunately, the discussion quickly derailed towards the concatenation operator * for strings).

I think in the mean time $ is dispatched for more types than just (Bool, Bool), which is rather unfortunate. For Bool types, the operator could be replaced by ^. (Currently x::Bool ^ y::Bool has the semantics of "y implies x", which was not intended IMHO). [@jiahao: edited from discussion below; ^ is exponentiation]

It would be great to have $ free/deprecated before julia-0.6/1.0 is finalised. My personal favourite is that x$y is, somehow, interpreted as x[:y]. See also the the discussion at #1974 .

[stevengj]

If we want x.y overloading (I do!), we should just implement that. (Note that you really want something like x[Val{:y}] so that it can be dispatched at compile-time.)

I don't think it would be a good idea to use ^ for both xor and exponentiation.

That being said, I'm inclined to agree that xor is uncommon enough that there's no need to define an ASCII binary operator for it. We could just use xor(a,b), and maybe const ⊻ = xor (\veebar<tab>).

[JeffBezanson]

I agree this is a waste of an ASCII operator. I might even extend the argument to | and & as well.

x::Bool ^ y::Bool is exponentiation. For 0 and 1 arguments ^ happens to have the same truth table as "implies".

[carnaval]

For 0 and 1 arguments ^ happens to have the same truth table as "implies".

(not a coincidence, this is Curry-Howard :-))

[Sacha0]

I agree this is a waste of an ASCII operator. I might even extend the argument to | and & as well.

+1, and in event of consensus I would lend a hand in the deprecation effort. Ref. #5187 and #5238.

[stevengj]

| and & are really useful as non short-circuit boolean operators, so I would prefer to leave them as-is.

[tkelman]

not entirely as is, we should deprecate the vectorized | and & now that dot operators are becoming more widespread and will be part of the syntax. $ is used for a few too many things and wouldn't be missed quite as much in infix. a unicode version would do fine.

[TotalVerb]

👎 to using ^ for Bool types. It would be incredibly confusing to have different semantics of ^ for Bool and Int.

[davidavdav]

x::Bool ^ y::Bool is exponentiation

I figured that, I just thought that false ^ false referring to 0^0 would be undefined. But I see now that 0^0==1 for all numeric types. But anyway, let's not discuss using ^ for xor() any further, that was probably a bad idea.

[jiahao]

Did someone say Unicode? ⊻ is not defined...

I edited the OP to reflect the discussion of ^ being exponentiation.

[StefanKarpinski]

Here's my position:

• I'm all for getting rid of $ as infix xor. We can just have a function called xor.
• Unless we have an equally intuitive meaning for & and | I don't see much point in getting rid of their current meanings, since the other usage would just be more confusing.
• Bool^Bool cannot mean xor since that's operator punning which is the most basic no-no.

[JeffBezanson]

Sounds like it is resolved to deprecate $ to xor.

[davidavdav]

Great! Will anyone pick this up or should I dig into the code and try to submit a PR?

[omus]

I'd like to maintain having infix operators for all bitwise operations. Using a unicode operator such as ⊻ or ⊕ (\oplustab) would be fine for this purpose.

[omus]

Alternatively, since bitwise operators aren't used very frequently we could always use a macro and stick to the traditional C bitwise operators.

@bitwise a ^ b  # XOR
a ^ b  # Exponentiation

I could also see this leading to confusion. Just a thought.

[TotalVerb]

I'm ok with ⊻ (\veebar), but ⊕ is too useful for other stuff to be used for XOR, IMO.

[stevengj]

Yes, ⊻ is literally defined by Unicode as xor, whereas ⊕ has other uses.

[BobPortmann]

+100 to the use of $ to make x$y be interpreted as x[:y]. If x is a {Symbol,Any} dict (or custom Associative type) and it holds an array then x$y[i,:,j] is much nicer than x[:y][i,:,j] (the gain is larger if there are multiple levels of dicts).

[StefanKarpinski]

The reason you're getting some thumbs down is that people would prefer to have x.y meaning x[:y] and use the $ for something else altogether, which I have to confess I agree with.

[BobPortmann]

I originally wanted x.y to mean x[:y] as well and would still be happy with it. But x$y would avoid some of the negatives of dot overloading, e.g.
-having to use something like x..y for true member access
-people abusing it to make julia look like a OO language

[davidavdav]

So, then Base would define something along the lines of

getfield(t, member) = t..member
getfield(dict::Associative{Symbol}, key::Symbol) = dict[key]
getfield(dict::Associative{String}, key::Symbol) = dict[string(key)]

if . would translate to getfield() and .. would be the current .?

[stevengj]

@davidavdav, see the discussion in #1974 and the attempted implementation in #5848; further discussion of getfield overloading should happen in #1974.

[LaszloHars]

I know, I am late in the party... Still, a standardized (extended) ASCII character for infix bitwise and Boolean XOR would be nice. The reasons:

• In Windows, REPL does not show \veebar with the default font, and in most other monospace fonts. The couple fonts, which show it makes the terminal almost unreadable
• The same is true for many code editors
• Sometimes we must save our code as a pure ASCII file, and avoid any Unicode characters. xor(A,...) looks ugly and harder to comprehend than infix notations. Coding and crypto algorithms contain long XOR chains, and converting them to functional notations makes the expressions look very different than in other programming languages
• If programmers define their own infix XOR symbol, others will have difficulty to understand the logic of the code

I tried to use the currency symbol for XOR: ¤. Other good candidates could be ¢, ¥, §, ©, ®, ¶...

[stevengj]

None of the characters you propose are ASCII; I guess you mean Latin1?

The world in which you can use Latin1 but not Unicode is quickly becoming a memory...

[LaszloHars]

This is what I meant with "extended" ASCII. I don't know, if multiple code pages have identical symbols. If anything is common, we might be able to use that.
50 Years ago I designed a programming language, where all the bitwise logic operations were denoted by 2-character infix codes: \/, /\, >< and <>. Could we use >< for XOR?

[stevengj]

Unicode turned the whole concept of "code pages" into a relic. Only one "code page" is allowed for Julia code, and that is UTF-8.

I agree that the shortcomings of the default Windows terminal (inadequate fonts being the least of them) is a persistent problem. It may be that we will simply have to bundle a better terminal on Windows; see #7267.