> On Sep 1, 2017, at 6:04 AM, André “Zephyz” Videla <[email protected]> > wrote: > >> 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)
Floating-point addition isn't associative, and integer addition as we define it in Swift isn't even total. Anyway, we're not going to re-syntax string concatenation in the 5th major release of the language. If you want to use a different operator for it, you are welcome to define one in your own code, as well as to ask for ways to hide the one from the standard library. John. > On 1 Sep 2017, at 03:27, John McCall <[email protected] > <mailto:[email protected]>> wrote: > >>> On Aug 31, 2017, at 8:51 PM, André “Zephyz” Videla via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>>> On Aug 31, 2017, at 3:40 PM, André Videla via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
