#### Shiny New Things: [Unicode Operators](http://nim-lang.github.io/Nim/manual_experimental.html#unicode-operators) are available under an experimental flag. RFC is [here](https://github.com/nim-lang/RFCs/issues/388)
codepoint| name| category | code block ---|---|---|--- u+00b1| plus-minus sign| Math Symbol | Latin-1 Supplement u+00d7| multiplication sign| Math Symbol | Latin-1 Supplement u+2218| ring operator| Math Symbol | Mathematical Operators u+2219| bullet operator| Math Symbol | Mathematical Operators u+2295| circled plus| Math Symbol | Mathematical Operators u+2296| circled minus| Math Symbol | Mathematical Operators u+2297| circled times| Math Symbol | Mathematical Operators u+2298| circled division slash| Math Symbol | Mathematical Operators u+2299| circled dot operator| Math Symbol | Mathematical Operators u+229b| circled asterisk operator| Math Symbol | Mathematical Operators u+229e| squared plus| Math Symbol | Mathematical Operators u+229f| squared minus| Math Symbol | Mathematical Operators u+22a0| squared times| Math Symbol | Mathematical Operators u+22a1| squared dot operator| Math Symbol | Mathematical Operators u+2227| logical and| Math Symbol | Mathematical Operators u+2228| logical or| Math Symbol | Mathematical Operators u+2229| intersection| Math Symbol | Mathematical Operators u+222a| union| Math Symbol | Mathematical Operators u+2293| square cap| Math Symbol | Mathematical Operators u+2294| square cup| Math Symbol | Mathematical Operators u+2605| black star| Other Symbol| Miscellaneous Symbols . #### Cool! Why this subset of Unicode, though? I am, in general, in favour of extending Nim to use unicode symbols for mathematical/scientific purposes. (I personally wanted a wreath product a few months back) But since adding this support requires hard-coding them into the parser, and since allowing one version of a subset of similar-looking glyphs de-facto disallows all others, I think we should be more circumspect, both in selecting which glyphs to include, and which code points to use to represent those glyphs. For example, the linked discussion didn't address at all the decision to use "bullet operator" over "dot operator". Looking at them on programmingfonts.org, there is no clear case whereby one is bigger than the other, so using that distinction can not be relied on to make a decision (irrespective of how subjective choosing the bigger or smaller one would be). This is not to say that objective criteria do not exist for choosing one of a (admittedly subjectively identified) subset of glyphs, there's at least a partial ordering based on: * commonality of usage * inclusion on keyboards, both physical and virtual * inclusion in other pre-existing sets of glyphs or code-points, * naming, categorization, and notes by the unicode consortium By pre-existing sets I mean things like: named html escapes, glyphs used in APL or codepoints supported by Julia, glyphs described in [glossaries](https://en.wikipedia.org/wiki/Glossary_of_mathematical_symbols) , and, to a lesser extent, the actual codepoints used in a wikipedia article. #### What's up with Black Star? It's on Nim's list because "star operator" and "asterisk operator" are both supported as infix operators in Julia, but those are very hard to distinguish from each other and from * #### How cargo cult was that decision? Julia cast a very wide net, enabling most of the 'mathematical operators' category. so julia does it because unicode. unicode also tends to err on the side of more codepoints. The "star operator"(U+22C6) exists in unicode because of APL (see the notes under the codepoint in the [spec](https://www.unicode.org/charts/PDF/U2200.pdf)) which uses it for exponentiation. However, according to the [unicode compatibility table](https://aplwiki.com/wiki/Unicode) on the apl wiki, the standard asterisk(u+002a) is the only universally implemented character, being unambiguous in APL. I can't find much about it but my impression is that "asterisk operator"(U+2217) exists in unicode as an attempt to semantically distinguish mathematical from typographical uses of the asterisk. This prescriptivism has not worked for other glyphs: everyone uses "hyphen-minus"(U+002d) as the mathematical operator, even though the technically correct "minus sign" exists at U+2212, and how everyone uses "solidus"(U+002f) instead of "fraction slash"(U+2044) or "division slash"(U+2215) #### Say something nice about it: U+2605 is enterable on an android keyboard by long-pressing * , (but not on ios) It has a named html escape: `&starf` It has the Unicode property "Other_Math", (but so do ♀ ♂ ♠ ♡ ♢ ♣) #### What's a bullet operator? I have no idea, but it's one of these 15 distinct glyphs: ··᛫•․‧∙⋅⸱⸳・𐄁ꞏᐧ･ #### Good god. which one should we use for, like, dot products? I think there are two candidates, depending on whether you value ease of access or unicode semantics The easiest to enter on a mobile keyboard is "bullet"(U+2022), it's just right there on android, or long-press - on ios The bog standard Latin-1 Supplementary "middle dot"(U+00b7) has been around for ages, but while it's available on android (long press -) it's not enterable from the keyboard on ios so it's less useable than 'bullet' and unicode "dot operator"(U+22c5) comes with the note "preferred to 00B7 · for denotation of multiplication" #### Shout-out to the wreath product In all the other operator choices, we choose ease of access over technical correctness. For a general purpose language, I'd rather have the evocative (and typeable) § than the technically correct ≀ #### TL;DR making black star an operator is copying bad design. "bullet" or "dot operator" make more sense than "bullet operator" Thank you for coming to my ted talk
