<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I use Mathematica, which under the covers is very Lisp like, though with names outside the brackets, comma separators, and square brackets. EG `a + b` is really:<div><br></div><div>&nbsp; &nbsp; Add[a, b]</div><div><br></div><div>The editor however supports all sorts of input formats including the above two and renders in full mathematical glory, e.g.:</div><div><br></div><div>&nbsp; &nbsp; Integrate[a Sin[:theta:], {:theta:, 0, :pi:}]</div><div><br></div><div>The above displays, could be entered with, and can be edited with full integral sign with limits, Greek, etc. Note how space (between a and Sin) is a shortcut for * in Mathematica. Also you don’t enter spaces (other than multiply) or layout text, the editor does those (though you can override) in a word processor style dynamic layout. Different fonts are extensively used and comments contain rich text and images and diagrams (like playgrounds).&nbsp;</div><div><br></div><div>Food for thought about what might be possible for a Swift editor.&nbsp;<br><br><div id="AppleMailSignature">-- Howard.</div><div><br>On 1 Sep 2017, at 11:27 am, John McCall via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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&nbsp;</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) -&gt; Measurement is not even associative.</div></div></div></blockquote><div><br class=""></div>It's not a group operation, but it is consistent with the concept of scalar multiplication in a vector space. &nbsp;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>&nbsp;and it's simply understood that <i class="">i</i>&nbsp;and <i class="">j</i>&nbsp;are in fact independent indices into the family <i class="">S</i>. &nbsp;You could undoubtedly design a parser that understood that sort of rule, but would it ultimately parse a reasonable programming language? &nbsp;I don't think so.</div><div><br class=""></div><div>I would argue that there is a much broader philosophical truth here. &nbsp;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. &nbsp;That is, Dave Sweeris's mathematicians and physicists are almost certainly misunderstanding their confusion: saying that the syntax is wrong&nbsp;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. &nbsp;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. &nbsp;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) -&gt; 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&nbsp;<span style="background-color: rgba(255, 255, 255, 0);" class="">⊗</span>) and consistent across codebases.&nbsp;</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 &lt;<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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) -&gt; 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="">--&nbsp;</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><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>