www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unicode operators and precedence?

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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!"⊙"
Oct 31 2020
parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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)
Nov 01 2020
next sibling parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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)
Nov 01 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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
Nov 01 2020
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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".
Nov 01 2020
parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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.
Nov 01 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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∁"
Nov 01 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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
Nov 01 2020
prev sibling parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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).
Nov 02 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Nov 02 2020