<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">It's not a group operation, but it is consistent with the concept of scalar multiplication in a vector space. </span></font></blockquote><br></div><div>That is exactly what I am suggesting: Have a dedicated scalar multiplication operator.</div><div><br></div><div>I think there is a misunderstanding here, I do not think that anyone here wants to write Swift like they write mathematical proofs. The link with operators and mathematics is that mathematics makes heavy use of “notation abuse” where everything has a special notation and a lot of those notation are confusing, inconsistent and conflict with other notation. And infix (and mixifx) operators allow some form of abuse.</div><div><br></div><div>I cannot talk for Dave Sweeris’s mathematician and physicists, but I can give you an example where users have no mathematical expectations but still expect some consistency in notation: Children learning programming.</div><div><br></div><div>Whenever you explain that you can use operators on your keyboard to do simple things like “adding two numbers together with +” and “combining two strings with +” you will often find students that ask “does that mean we can add together strings of text?” or “I do not understand why “3” + “4” is “34” and not “7”. My proposition to alleviate this problem woud make “3” + “4” a type error (since strings are not a commutative monoid)</div><div><br>On 1 Sep 2017, at 03:27, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 8:51 PM, André “Zephyz” Videla via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">these versions of the math operators don't quite work the same way as the standard ones (e.g. `+` can throw), but they still carry math semantics </span></font></div></blockquote></div><div class=""><br class=""></div><div class="">That is exactly what I argue should be avoided. When you see `+` you don’t expect it to throw. What’s more they don’t carry “math” semantics at all because for example</div><div class=""><br class=""></div><div class="">Func * (Double, Measurement) -> Measurement is not even associative.</div></div></div></blockquote><div><br class=""></div>People sometimes forget that mathematical notations are in fact <i class="">human</i> languages, which is it say that they're heavily ambiguous and contextual; there are plenty of texts where you see things like <i class="">S_ij</i> and it's simply understood that <i class="">i</i> and <i class="">j</i> are in fact independent indices into the family <i class="">S</i>. You could undoubtedly design a parser that understood that sort of rule, but would it ultimately parse a reasonable programming language? I don't think so.</div><div><br class=""></div><div>I would argue that there is a much broader philosophical truth here. Programming is not, and never can be, a pure exercise in mathematics, and the concepts necessary for understanding programming are related to but ultimately different from the concepts necessary for understanding mathematics. That is, Dave Sweeris's mathematicians and physicists are almost certainly misunderstanding their confusion: saying that the syntax is wrong implies that there could be a syntax that could be right, i.e. a syntax that would allow them to simply program in pure mathematics. That is a misapprehension just as deep as the belief that there could be a programming language that would allow one to simply program in conversational English or Korean. Even the ability to extract code from a proof assistant like Coq or Agda — and writing a proof in Coq or Agda is pretty far from the daily grind of most mathematicians — doesn't belie this, because ultimately the exact code extracted matters to a programmer in a way that the exact form of a known-valid proof does not matter to a mathematician.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">I agree that operators for this kind of functions should exist and are the right syntactic tool. But I disagree with the current implementation. My proposition for the example of `*` is as follow:</div><div class=""><br class=""></div><div class="">This signature happens quite often `(Number, T) -> T`. It would seem quite intuitive to have a dedicated operator for all “Scalar multiplication” which would be visually distinct from `*` (for example **, or Unicode <span style="background-color: rgba(255, 255, 255, 0);" class="">⊗</span>) and consistent across codebases. </div><div class=""><br class=""></div><div class="">For a + operator that throws, I would imagine a “TryAddable” protocol with a `+!` operator which can throw. I agree that it is visual noise, but I argue that it has tremendous value: consistant operator semantics.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">(Also, I really doubt changing concatenation to `++` is going to fly. Swift is not Haskell.)</span></font></div></blockquote>I doubt those remarks are very constructive. The point still stands: I find value in having different operators for different semantics.</div><div class=""><br class="">On 1 Sep 2017, at 01:54, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 3:40 PM, André Videla via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Something I could imagine is deprecate operator overloading and constrain them to a single Type. For example, the operator `+` could be constrained to the protocol `Addable` and has the signature `infix func + (Self, Self) -> Self` and is commutative. Similarly, we could have a protocol `Concatenable` which has its own operator (e.g.: ++ ) and is not commutative.</span></div></blockquote></div><div class=""><br class=""></div><div class="">These are basically "bag of syntax protocols" which aren't really usable generically, so we don't want this design. And if you tied this to the numeric protocols, then you couldn't use `+` for things that are numeric-ish but don't quite fit the protocols. For instance, I have a library that adds `+` and `*` operators to `Foundation.Measurement`; these versions of the math operators don't quite work the same way as the standard ones (e.g. `+` can throw), but they still carry math semantics and so `+` is the right operator for them. If `+` was exclusively tied to a particular protocol with a particular signature, I wouldn't be able to do that.</div><div class=""><br class=""></div><div class="">(Also, I really doubt changing concatenation to `++` is going to fly. Swift is not Haskell.)</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></body></html>