My answer is philosophical, and possibly not what is wanted, but it is informed. Here goes:
Backstory: Unary Minus, as taught in computer science and implemented in languages and instruction sets and so forth is slightly confusing and often confusingly described. x := -y // means get the value of y, negate that, and assign to the location known as x. This is what we commonly think of when seeing unary minus. It is proper. However this… x := -3 // does NOT mean get the value 3, negate that, and assign to the location known as x. …instead it means “assign the value ⁻3 to x”, where negative 3 is a single idea, not two as in (Negate 3). The raised minus sign is from Kenneth Iverson, who used it in APL to make the point that the ‘⁻’ and ‘-‘ have entirely different meanings. There is a Wikipedia article about this but its scholarship is, well, more about usage than history. They talk about the raised minus as an elementary school teaching tool (which it may be) but they leave it there with little suggestion of its illustrious past. Yet, to their credit there is a handy example: ⁺3 − ⁻5 becomes ⁺3 + ⁺5 = ⁺8 where you might imagine a teacher saying “positive three minus negative five becomes…” which is nice. (A sophisticated college CS teacher or parser coder might instead say “plus 3 minus minus 5 becomes…” ;-) We don’t have the raised minus to say “here is a negative number” so we make use of the unary rather than binary minus to suggest negative. You use what you have. Now, on to the original question: Standard floating point output since the 1950’s has allowed printing of either blank or “+” as the prefix for positive floating point values and, necessarily, the lowered minus “-“ for negative values; we get the ‘+’ with a printf format like “%+10.4f”. It is handy to be able to parse what is output, such as numerical approximations and weights in formula source code, so the parsing of “3.1415” was made to accept “+3.1415” for the same meaning, and of course “-3.1415” since we lack the raised minus. Since floating point values accept the stylistic ‘+’ prefix, so do integer values. ..and here we are today, some 50 years later. P.S. If you visited Thomas Payne’s bookshop in London (in the 1750s) you could have bought your own copy of Francis Maseres’ “A dissertation on the use of the negative sign in algebra: containing a demonstration of the rules usually given concerning it; and shewing how quadratic and cubic equations may be explained, without the consideration of negative roots. To which is added, as an appendix, Mr. Machin's quadrature of the circle.” You could have enjoyed much discussion of the new style of writing and its advantages. From: "'Thomas Bushnell, BSG' via golang-nuts" <golang-nuts@googlegroups.com> Reply-To: "Thomas Bushnell, BSG" <tbushn...@google.com> Date: Friday, August 19, 2016 at 1:36 PM To: Axel Wagner <axel.wagner...@googlemail.com>, Rob Thornton <rthornton...@gmail.com> Cc: golang-nuts <golang-nuts@googlegroups.com> Subject: Re: [go-nuts] Unary + In C, the type is promoted. But this ain't C. No clue what the point is in Go. It would function as a compile-time type-check for "numeric" I guess, but what would be the point? On Fri, Aug 19, 2016 at 1:32 PM 'Axel Wagner' via golang-nuts <golang-nuts@googlegroups.com> wrote: x would already be signed during implicit type inference. The inferred type is either the one specified in an argument or declaration, or it's the default type (which is int, thus signed). I don't know the answer to your question though. I didn't even know this existed… On Fri, Aug 19, 2016 at 9:54 PM, Rob Thornton <rthornton...@gmail.com> wrote: What is the purpose of the unary '+' operator? In both C and Go they are syntactically correct but neither generate instructions to modify the expression. The '-' operator obviously generates a neg or sub from 0 instruction to negate the result by inverting the expression with an add with carry. I know of no single instruction or pair of instructions to reliably ensure any value or expression is always positive so why include this unary operator at all? Is there a purpose I'm missing? Or is it just for clarity or force an implicit variable to be signed? As in: x := +5 Would this ensure that x must be signed during impicit type inference? If I read the specification correctly, this would also affect the resolution of untyped constants. Is this correct? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
