<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Just a side observation…<div class=""><br class=""></div><div class="">One of the downsides I would put forward to notation like this is it massively increases the barrier to entry for anyone else. I look at that “Reduction.agda” file and wonder if I need to go back to school for a degree in Math just to understand what’s going on.</div><div class=""><br class=""></div><div class="">On the other hand, while using inefficient matrix notation may be more verbose, it <i class="">is</i> consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.</div><div class=""><br class=""></div><div class="">Dave</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 3:13 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I would like to mention two things that I didn’t see mentioned in this thread (and if so, not emphasied enough since I missed it)<div class=""><br class=""></div><div class="">1. Swift already has pretty good unicode support, operators like ∷ for `cons` or prefix operators like `==` for partial functions work extremely well. Coincidentally I have written a bit about it on this blog post: <a href="https://medium.com/@andre_videla/elegant-swift-ec702fc84f11" class="">https://medium.com/@andre_videla/elegant-swift-ec702fc84f11</a></div><div class=""><br class=""></div><div class="">If matrix literals were added, we could imagine that the current operator support would make their use extremely readable to the trained eye. The only concern that I have on the subject is about overloading resolution: Being a heavy operator user, I see the error “Expression too complex, could not be inferred in reasonable time” more often that I would like. So even if support for fancy “non-typewriter-style” code were to be implemented in the language. Overload resolution would need to be much more robust than it currently is.</div><div class=""><br class=""></div><div class="">2. There already exists a programming language that experiments with unicode AND mixfix operator support making it the perfect playground for trying out other style of “code input”. This language is Agda. </div><div class=""><br class=""></div><div class="">Agda is quite the experimental playground and that’s why it’s useful to look at what it’s done. Mostly used by academic, their users do not have to share code across large scales of peoples and time. And even then, my limited and anecdotical, experience tells me that users have struggles simply copying their Agda code snippets to LaTeX on their own machine, let alone sharing it with other people across different systems. </div><div class=""><br class=""></div><div class="">Here is an example of unicode mixfix operator in Agda <span style="color: rgb(36, 41, 46); font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; background-color: rgb(255, 255, 255);" class=""><a href="https://github.com/sstucki/system-f-agda/blob/8ebbe32968c3ec9e046240cc6621166adcd23180/src/SystemF/Reduction.agda#L224" class="">https://github.com/sstucki/system-f-agda/blob/8ebbe32968c3ec9e046240cc6621166adcd23180/src/SystemF/Reduction.agda#L224</a></span></div><div class=""><div class=""><br class=""></div><div class="">Another programming language inspired by Agda, Idris, completely ditched unicode and mixfix operator for reasons exposed here: </div><div class=""><a href="https://github.com/idris-lang/Idris-dev/pull/694#issuecomment-29559291" class="">https://github.com/idris-lang/Idris-dev/pull/694#issuecomment-29559291</a></div></div><div class=""><br class=""></div><div class="">With that said, I have to concede that I am quite fond of unicode operators and quite jealous of Agda mixfix syntax. It is truly a pleasure to read `<span style="color: rgb(36, 41, 46); font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; white-space: pre; background-color: rgb(255, 255, 255);" class="">check Γ ⊢ t ∈ a</span>` (from the definition `<span style="color: rgb(36, 41, 46); font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; white-space: pre; background-color: rgb(255, 255, 255);" class="">check _ ⊢ _ ∈ _</span>` where underscores are the position of the argument of the function) instead of some verbose description that is not linked in anyway with the traditional representation of the function.</div><div class=""><br class=""></div><div class="">Even though my personal opinion brings me to enjoy unicode operators and code that looks like arcane incantations, I have to admit that this particular feature does not participate strongly in making Swift a strictly better language. Indeed, how do we achieve world domination if Swift code cannot be reliably shared across many people, in many countries, many cultures, and many different input devices and symbol conventions?</div><span class=""><span class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">PS: agda even has “IDE” support with unicode input in emacs <a href="http://agda.readthedocs.io/en/latest/tools/emacs-mode.html?#unicode-input" class="">http://agda.readthedocs.io/en/latest/tools/emacs-mode.html?#unicode-input</a></div></span></span><span class=""><div class=""><br class=""></div></span><div class=""><blockquote type="cite" class=""><div class="">On 31 Aug 2017, at 22:13, John McCall 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=""><div 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;" class=""><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class="">Where is the source for this number? XCode is not even available for Linux. And XCode’s market share is only shrinking as Swift expands more into the open source world. To make Swift depend on proprietary XCode features would nullify all of the work that has been done in the past 2 years to bring Swift to Linux platforms.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Aug 31, 2017 at 12:44 PM, John Pratt<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jprattx@gmail.com" target="_blank" class="">jprattx@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class="">XCode is not just one of many editors to edit Swift you asshole.</div></div></blockquote></div></div></div></blockquote><div class=""><br class=""></div>John, this sort of personal attack is not acceptable behavior in the Swift community, and sending it privately does not alter that. If you would like to continue participating in this community, please learn to treat your fellow contributors with respect.</div><div 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;" class=""><br class=""></div><div 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;" class="">I don't think this thread is entirely off-topic. While Swift as a language is committed to allowing code to be edited in a simple text editor, we also recognize the importance of graphical programming environments, and we are certainly open to adding features that primarily benefit them — as we did with color and resource literals. Of course, it would necessary to show that the language feature was both necessary and likely to see significant editor adoption. At least some of these ideas, like rendering a power operator with a superscript, do seem like they could implemented in an editor without any language support.</div><div 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;" class=""><br class=""></div><div 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;" class="">John.</div><div 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;" class=""><br class=""></div><div 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;" class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><div class="h5"><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 11:27 AM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_-1782199036737315374Apple-interchange-newline"><div class=""><div dir="ltr" class="">If you ask me this thread is off topic and belongs on an Apple issue tracker or forum. XCode is just one of many editors used to edit Swift code, and it should by no means be used as a baseline for language design considering it is closed source and only available on one platform, compared to a large number of great open source editors.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word;">A few thoughts:<div class=""><br class=""></div><div class="">1) I would like to see Xcode gain a couple more literal types using the same strategy it does for Image and Color literals</div><div class=""><br class=""></div><div class="">2) I would LOVE to see simple equation typesetting in Xcode</div><div class=""><br class=""></div><div class="">(Those two are mostly up to the Xcode team as opposed to swift, I suppose)</div><div class=""><br class=""></div><div class="">3) Why are we pretending like we can always edit swift in a ASCII editor? The argument that actually using unicode would break things doesn’t seem valid, because Swift has supported unicode since version 1, and people have been using it since that time to name both variables and operators. That doesn’t mean we need a super fancy editor, but I think requiring unicode awareness is completely reasonable. If your editor from the 1970’s breaks something, it is both your and your editor’s fault, not the code or the library, because Swift has unicode in it’s spec.</div><div class=""><br class=""></div><div class="">4) I don’t think we should let the difficulty of typing certain things stop us. It is an issue we need to consider, but it is an issue which can be solved fairly easily with good UI design if there is a need. Sure, different editors might solve it in different ways, but they will all solve it if it is useful (and in a few years, we will have all settled on the best approach). As people have mentioned, it can be difficult to type ‘{‘ on certain language layouts, so if we limited ourselves by that we couldn’t do anything. We shouldn’t adopt a lowest common denominator approach.</div><div class=""><br class=""></div><div class="">5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It<span class="Apple-converted-space"> </span><b class="">won’t</b><span class="Apple-converted-space"> </span>be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by Apple in the late 80’s that proves this). We all learned the symbol in math class. Even non-programmers know what it means. Assigning it any other meaning would be confusing because it’s meaning is so widely known. Every time I bring this up, I am told to just roll my own (which I have)… but it means that my code will now clash with everyone else’s identical implementation (because there is only one sane way to implement it). The fact that there are multiple identical implementations interfering with each other (and no real way to make a significantly different implementation) tells me it really should be part of swift itself. Every time I bring it up, people complain about it being extended ASCII instead of pure ASCII, and that it is hard to type on a German keyboard (those people can either just type ‘<=‘ or use a better editor which autocompletes ‘<=‘ to ‘≤’).</div><div class=""><br class=""></div><div class="">6) My recommendations for typing symbols would be:</div><div class=""><span class="m_-1782199036737315374m_-7968505672863582989Apple-tab-span" style="white-space: pre-wrap;"> </span>a) Choose a subset of useful and well-known symbols instead of every symbol</div><div class=""><span class="m_-1782199036737315374m_-7968505672863582989Apple-tab-span" style="white-space: pre-wrap;"> </span>b) Allow autocomplete on those symbols by name</div><div class=""><span class="m_-1782199036737315374m_-7968505672863582989Apple-tab-span" style="white-space: pre-wrap;"> </span>c) Optionally choose a little-used guardian character to start the names of symbols (to avoid accidental autocompletion). </div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><span class=""><div class="">On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1782199036737315374m_-7968505672863582989Apple-interchange-newline"></span><div class=""><div class=""><div class="m_-1782199036737315374h5"><div class="" style="word-wrap: break-word;">I sent a postal envelope to the Swift team with an article I wrote, arguing that<div class="">symbols and graphics would push the programming language forward.</div><div class=""><br class=""></div><div class="">Wouldn’t it be nice to have an actual multiplication matrix broken out into code,</div><div class="">instead of typing, “matrix()”? It seems to me Swift has the chance to do that.</div><div class=""><br class=""></div><div class="">Also: why does "<==" still reside in code as "less than or equal to” when</div><div class="">there is a unicode equivalent that looks neat? </div><div class=""><br class=""></div><div class="">Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)? </div><div class="">I think this would make programming much easier to deal with.</div><div class=""><br class=""></div><div class="">I expound on this issue in my article:</div><div class=""><br class=""></div><div class=""><a href="http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf" target="_blank" class="">http://www.noctivagous.com/nct<wbr class="">_graphics_symbols_prglngs_draf<wbr class="">t2-3-12.pdf</a></div><div class=""><br class=""></div><div class="">Thank you for reading.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-John</div></div></div></div><span class="">______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class=""></div></div><br class="">______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="" 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;"><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="">_______________________________________________</span><br 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;" 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="">swift-evolution mailing list</span><br 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;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br 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;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>