> It's not a group operation, but it is consistent with the concept of scalar > multiplication in a vector space.
That is exactly what I am suggesting: Have a dedicated scalar multiplication operator. 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. 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. 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) > On 1 Sep 2017, at 03:27, John McCall <rjmcc...@apple.com> wrote: > >>> On Aug 31, 2017, at 8:51 PM, André “Zephyz” Videla via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> 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 >> >> >> 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 >> >> Func * (Double, Measurement) -> Measurement is not even associative. > > People sometimes forget that mathematical notations are in fact human > languages, which is it say that they're heavily ambiguous and contextual; > there are plenty of texts where you see things like S_ij and it's simply > understood that i and j are in fact independent indices into the family S. > 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. > > 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. > > John. > >> 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: >> >> 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 ⊗) and >> consistent across codebases. >> >> 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. >> >>> (Also, I really doubt changing concatenation to `++` is going to fly. Swift >>> is not Haskell.) >> I doubt those remarks are very constructive. The point still stands: I find >> value in having different operators for different semantics. >> >>> On 1 Sep 2017, at 01:54, Brent Royal-Gordon <br...@architechies.com> wrote: >>> >>>> On Aug 31, 2017, at 3:40 PM, André Videla via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> 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. >>> >>> >>> 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. >>> >>> (Also, I really doubt changing concatenation to `++` is going to fly. Swift >>> is not Haskell.) >>> >>> -- >>> Brent Royal-Gordon >>> Architechies >>> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
