If D had more operators, specifically the ones in the Unicode spec. Which ones should be available and what would the precedence order be in relation to the existing ones?

Suggestions:

opUnary!"√"
opBinary!"·"
opBinary!"≈"
opBinary!"≉"
opBinary!"∩"
opBinary!"∪"
opBinary!"⊂"
opBinary!"⊃"
opBinary!"⊄"
opBinary!"⊅"
opBinary!"⊆"
opBinary!"⊇"
opBinary!"⊈"
opBinary!"⊉"
opBinary!"∈"
opBinary!"∉"
opBinary!"✕"
opBinary!"⊕"
opBinary!"⊖"
opBinary!"⊗"
opBinary!"⊘"
opBinary!"⊙"

On Saturday, 31 October 2020 at 11:32:09 UTC, Ola Fosheim Grøstad wrote:
> If D had more operators, specifically the ones in the Unicode spec. Which ones should be available and what would the precedence order be in relation to the existing ones?
>
> Suggestions:
>
> opUnary!"√"
This should also be binary (to calculate the n.th root, with n an integer >= 2)
The priority should be rather high.

> opBinary!"·"
Don't we already have the dot operator (with much too many meanings)?
If you mean some different character, I would recommend to refrain from it as it is visual too similar.

> opBinary!"≈"
> opBinary!"≉"
> opBinary!"⊂"
> opBinary!"⊃"
> opBinary!"⊄"
> opBinary!"⊅"
> opBinary!"⊆"
> opBinary!"⊇"
> opBinary!"⊈"
> opBinary!"⊉"
> opBinary!"∈"
> opBinary!"∉"
All the comparison operators should have a very low priority, equal to those of >, <, != etc.

> opBinary!"✕"
> opBinary!"⊗"
> opBinary!"⊘"
> opBinary!"⊙"
same as *, / ("point" arithmetic)

> opBinary!"⊕"
> opBinary!"⊖"
same as +, - ("stroke" arithmetic)

> opBinary!"∩"
> opBinary!"∪"
same as &, |, ^ ("set" arithmetic - bitwise is only a special kind of set)

On Sunday, 1 November 2020 at 19:47:33 UTC, Dominikus Dittes Scherkl wrote:
And with Unicode we could of course replace all the clunky two-char operators or misused characters with standard dedicated single chars:

!= --> ≠
<= --> ≤
'>= --> ≥
== --> = (compare)
=  --> ≔ (assign)
!  --> ¬ (logic not)
&& --> ∨ (logic and)
|| --> ∧ (logic or)
^  --> ⊻ (xor - and add the missing ⊼ (nand) and ⊽ (nor))
&  --> ∪ (union)
|  --> ∩ (intersection)

On Sunday, 1 November 2020 at 19:47:33 UTC, Dominikus Dittes Scherkl wrote:
>> opUnary!"√"
> This should also be binary (to calculate the n.th root, with n an integer >= 2)
> The priority should be rather high.

Thanks, that was an interesting suggestion!

>> opBinary!"·"
> Don't we already have the dot operator (with much too many meanings)?
> If you mean some different character, I would recommend to refrain from it as it is visual too similar.

It is center-dot, multiplication/inner product: vec1·vec2

On macs you get it with alt+"." I think. IDEs should colour it differently than the regular "vec1.length" operator, so I think it will work. But won't know until I try.

>> opBinary!"✕"
>> opBinary!"⊗"
>> opBinary!"⊘"
>> opBinary!"⊙"
> same as *, / ("point" arithmetic)

I wonder if they should be one step higher so that they can be used for linear algebra? But I am not sure.

It would be nice to do "3*vec1 ✕ 4*vec2" and have it parse as
"(3*vec1) ✕ (4*vec2)"


>> opBinary!"∩"
>> opBinary!"∪"
> same as &, |, ^ ("set" arithmetic - bitwise is only a special kind of set)

IIRC D uses the same as C where "&", "|" have higher precedence than "==" which is not good.

I want to be able to say "A∩B == C" and have it parse as "(A∩B) == C".

On Sunday, 1 November 2020 at 20:09:17 UTC, Dominikus Dittes Scherkl wrote:
> On Sunday, 1 November 2020 at 19:47:33 UTC, Dominikus Dittes Scherkl wrote:
> And with Unicode we could of course replace all the clunky two-char operators or misused characters with standard dedicated single chars:
>
> != --> ≠
> <= --> ≤
> >= --> ≥

Yes, I have implemented those.

> == --> = (compare)

Yes, I have that (not on github), but with a different filename extensions so that one can compile D-files and experimental D syntax in the same build.

> =  --> ≔ (assign)

Maybe a bit difficult to see?
I have implemented a unicode left arrow for assignment.

Actually these are in, you can use both syntaxes in the same .d file:

NEW: symbol‹…›
OLD: symbol!(…)

NEW: x ⟵ expr
OLD: x = expr

NEW: symbol ≡ type
OLD: alias symbol = type

(I think this should be used for manifest constants too, but not sure how to implement it yet.)

NEW: x ≤ y
OLD: x <= y

NEW: x ≥ y
OLD: x >= y

NEW: x ≠ y
OLD: x != y


> !  --> ¬ (logic not)
> && --> ∨ (logic and)
> || --> ∧ (logic or)
> ^  --> ⊻ (xor - and add the missing ⊼ (nand) and ⊽ (nor))

I was thinking to use those for bitwise operators in order to overcome the precedence mess that currently exists. So they would have lower precedence than equality. Also xor makes more sense bitwise.

I have some more ideas here (may change, and I don't know when I have time to start, more sure about the ones at the top than at the bottom.):

https://github.com/OlaFosheimGrostad/dex/blob/master/EXTENSIONS.md

On Sunday, 1 November 2020 at 20:15:00 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 1 November 2020 at 19:47:33 UTC, Dominikus Dittes Scherkl wrote:
>>> opBinary!"·"
>> I would recommend to refrain from it as it is visual too similar [to dot].
>
> It is center-dot, multiplication/inner product: vec1·vec2
> IDEs should colour it differently than the regular "vec1.length" operator
Ok, may work, but I still think it's no good idea.

>>> opBinary!"✕"
>>> opBinary!"⊗"
>>> opBinary!"⊘"
>>> opBinary!"⊙"
>> same as *, / ("point" arithmetic)
>
> I wonder if they should be one step higher so that they can be used for linear algebra? But I am not sure.
Yeah, one step higher prio would be good.

>>> opBinary!"∩"
>>> opBinary!"∪"
>> same as &, |, ^ ("set" arithmetic - bitwise is only a special kind of set)
>
> IIRC D uses the same as C where "&", "|" have higher precedence than "==" which is not good.
>
> I want to be able to say "A∩B == C" and have it parse as "(A∩B) == C".
I don't understand. if & | ^ had higher prio than == everything would be good.
SO yes, you are right, the prio of set operation should be higher than comparison.

> > !  --> ¬ (logic not)
> > && --> ∨ (logic and)
> > || --> ∧ (logic or)
> I was thinking to use those for bitwise operators in order to overcome the precedence mess that currently exists.

No, they are clearly logic operators and should NOT have set semantics.
Bitwise, as I mentioned, is only a special kind of set, so we should use the set operators to overload bitwise arithmetic (I always think of an unsigned value as a set of bits).
But I agree, logic should have higher prio than comparison, but lower prio than set operators.

> > ^  --> ⊻ (xor - and add the missing ⊼ (nand) and ⊽ (nor))
> Also xor makes more sense bitwise.
Hmm. Maybe you are right - Xor, Nand and Nor are more useful as additional set operators.
But And, Or and Not should be pure logic.

Ah, i missed one:
~  --> ∁ (complement)
And of course unary operators should have highest priority, no matter if they are set, logic or whatever.

On Sunday, 1 November 2020 at 20:52:10 UTC, Dominikus Dittes Scherkl wrote:
> I don't understand. if & | ^ had higher prio than == everything would be good.

I meant opposite. In C "&" has higher priority than "==".
https://en.cppreference.com/w/c/language/operator_precedence

I don't want "a&b == c" to parse as "a&(b==c)".

So I want "a∧b == c" to parse as "(a∧b) == c".

I am adding keywords "or", "and" "not" for boolean logic. And adding a special quotes «identifier» for creating identifiers. So if you in current D have "and(x,y)" then it can be transpiled to "«and»(x,y)".

I believe HackerPilot has a scanner-library that can be used for automatic code conversion.

> No, they are clearly logic operators and should NOT have set semantics.

Well, it depends on what kind of software one writes. You could also view an unsigned int as a vector of bools rather than a set.

> Hmm. Maybe you are right - Xor, Nand and Nor are more useful as additional set operators.

Nand and nor might be nice to have, not sure if people use them much, but.

> Ah, i missed one:
> ~  --> ∁ (complement)

I looked at that one, but it is virtually indistinguishable from a regular C. I guess it could work if one required it to be used like a function:

So allow "∁(MySet)" and disallow "∁MySet" and "MySet∁"

On Sunday, 1 November 2020 at 21:13:07 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 1 November 2020 at 20:52:10 UTC, Dominikus Dittes Scherkl wrote:
>> I don't understand. if & | ^ had higher prio than == everything would be good.
>
> I meant opposite. In C "&" has higher priority than "==".


Argh! I am tired. I meant:  In C "==" has higher priority than "&".

Don't listen to what I say, listen to what I mean… :-D

On Sunday, 1 November 2020 at 21:13:07 UTC, Ola Fosheim Grøstad wrote:
> I am adding keywords "or", "and" "not" for boolean logic.
Bah. Why?
>> No, they are clearly logic operators and should NOT have set semantics.
>
> Well, it depends on what kind of software one writes. You could also view an unsigned int as a vector of bools rather than a set.
Yes, but a vector is still a kind of set (only has much richer additional structure), so use set operators on it, not boolean logic. Boolean is for only one bit at a time.
I still think replacing & with ∩ and | with ∪ is the best way to go, so ∧ can be used instead of && and ∨ instead of ||. No need for words and all standard so everybody should know what they mean.
Also all of them are new, so precedence can be assigned to your wishes without braking existing code.
>
>> Hmm. Maybe you are right - Xor, Nand and Nor are more useful as additional set operators.
>
> Nand and nor might be nice to have, not sure if people use them much, but.
How could they, as the language doesn't offer them as operators?
I think in HW design at least Nand is heavily used...

>
>> Ah, i missed one:
>> ~  --> ∁ (complement)
>
> I looked at that one, but it is virtually indistinguishable from a regular C.
Ok, at least ~ is there and does not have a bad precedence so no urgent need to replace it by something different, although it is non-standard (at least for a mathematician).

On Monday, 2 November 2020 at 08:30:37 UTC, Dominikus Dittes Scherkl wrote:
> I still think replacing & with ∩ and | with ∪ is the best way to go, so ∧ can be used instead of && and ∨ instead of ||. No need for words and all standard so everybody should know what they mean.

I understand what you are saying, but set operators for this would be unusual in computing I think. Also, Xor, Nand and Nor should work on bitvectors.. so for consistency...

> Also all of them are new, so precedence can be assigned to your wishes without braking existing code.

But I think bitoperators should have higher precedence than set operators?

Lots of trade offs... for sure.

> How could they, as the language doesn't offer them as operators?
> I think in HW design at least Nand is heavily used...

Yes, might be useful for implementing algorithms from papers. Crypto etc. Easier to visually check for typos if the code in the IDE looks more like the code in the paper.

> Ok, at least ~ is there and does not have a bad precedence so no urgent need to replace it by something different, although it is non-standard (at least for a mathematician).

True, except "~" is used for concatenation that is completely unrelated. I think it would be nice to get a quick interpretation of code by humans (at least conceptually) by not using the same symbols for multiple meanings.

Hard to tell in advance what feels right, worth experimenting with.