Unicode operator symbols about curv

[TLC123]

I like some better than others.

90° == 90*deg Yes agree 
≤ ≥ ≠ Yes agree
¬a == !a No improvement 
a·b == dot(a,b) Mmh slightly unclear 
a×b == a*b or cross(a,b) -- not sure which is better Yes agree a×b 
a÷b Yes but no major improvement
√a  -- what is the precedence of the √ operator? Yes agree 
a∧b == a&&b  Nah not for me 
a∨b == a||b.    Nah not for me 
x→x+1   ==   x->x+1 Yes agree 
for (i ∈ 1..10) Not for me no
π == Pi Yes agree 
τ == tau Yes agree 
∞ == inf Yes agree
x↑y = x^y No less clear 

[bluecube]

IMO these are too complicated to write. Even if they all had an ascii alternative, this would only apply for fresh project. If I come to an existing project already using these, using the ascii versions breaks the style, so I'd end up copying every character from a few lines above. Not worth it. The excetption to this complaint is the degrees symbol, which is present on some regular keyboard maps (czech, for example) and has the amazing property of allowing both the API to be designed in radians (which is the more sane way) and not forcing the user to think in radians (which gets a bit uncomfortable). Kuba

…

---------- Původní e-mail ---------- Od: TLC123 <[email protected]> Komu: doug-moen/curv <[email protected]> Datum: 29. 10. 2018 16:22:57 Předmět: Re: [doug-moen/curv] Unicode operator symbols (#47) " I like some better than others. <code>90° == 90*deg Yes agree ≤ ≥ ≠ Yes agree ¬a == !a No improvement a·b == dot(a,b) Mmh slightly unclear a×b == a*b or cross(a,b) -- not sure which is better Yes agree a×b a÷b Yes but no major improvement √a -- what is the precedence of the √ operator? Yes agree a∧b == a&&b Nah not for me a∨b == a||b. Nah not for me x→x+1 == x->x+1 Yes agree for (i ∈ 1..10) Not for me no π == Pi Yes agree τ == tau Yes agree ∞ == inf Yes agree x↑y = x^y No less clear </code> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (#47 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAMla9YeUu4XrF4JhDG2_xDHxrHjF_X7ks5upx1LgaJpZM4X9j15) . "

[doug-moen]

The best reason to implement this feature is to make Curv programs easier to read.

The best reason not to implement this feature is what @bluecube said: it's too hard to type the Unicode characters.

I did some research, and it is not easy to configure all of your computers to have an easy to remember and uniform keyboard interface for typing Unicode technical symbols. Linux systems have a mechanism where you hold down the Compose key, type a 2 character mnemonic, and you get a technical symbol. For example, Compose <= gives ≤. And that's very nice. But you have to configure the Compose key, and you can't type a π this way unless you edit a config file and add a custom key binding. I don't yet know how to configure these same key sequences on a Macintosh. If there was a standard, cross platform solution that was easy to use and covered all of the popular technical symbols, then the Unicode operator feature would be more feasible.

Another alternative for making Curv programs easier to read is to store the program in ASCII on the hard drive, but configure your editor to use typographical tricks to make the on screen presentation more readable. Syntax colouring is one popular trick. Another is to use a programmer's ligature font, so that, for example, <= is presented on screen as ≤.
https://www.hanselman.com/blog/MonospacedProgrammingFontsWithLigatures.aspx

[doug-moen]

Based on @bluecube's comment, I don't think this is a good idea right now, so I'm going to close the issue.