[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

John McCall rjmccall at apple.com
Fri Sep 1 12:37:52 CDT 2017


> On Sep 1, 2017, at 6:04 AM, André “Zephyz” Videla <andre.videla at gmail.com> 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 <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
> 
>>> On Aug 31, 2017, at 8:51 PM, André “Zephyz” Videla via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>> 
>>>>> On Aug 31, 2017, at 3:40 PM, André Videla via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170901/f2e4fc47/attachment.html>


More information about the swift-evolution mailing list