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