<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Funny, of all the debates that have taken place on this list, the one that brings out the incivility is about editors... yet another way vim and emacs prove their relevance đ</div><div><br></div><div>Seriously though, is there any reason that *all* of these suggestions canât be left to the editor? Put another way: is the real desire here nicely formatted code in a file, or *nicely formatted code displayed on your screen*? I think the general opposition is to changing the language to accommodate these features; it doesnât seem like anyone is opposed to the features per se. Let your editor display <= as the less-than-or-equal symbol (canât type as Iâm on mobile) and convert a typed LToE symbol to <= in the file. Let your editor display x.intersect(y) as x \cap y and convert x \cap y to x.intersect(y) in the file. Etc etc. If the mathematical matrix becomes a significant part of the language, I suppose #matrix((row1 entries) (row2 entries) ... (rowN entries)) would be fine as well. But for ease of input and display across all computers and editors, the underlying code should remain easy to type on a typewriter. </div><div><br></div><div>My 2c.</div><div><br>On Aug 31, 2017, at 7:14 PM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Iâm sorry, I donât really understand the point youâre trying to make. Swift is open source. Anyone is free to make a Swift editor or integrate Swift support in to non-Apple IDEs, and then support additional features in their IDEs to make a custom-tailored Swift experience.</div><div class=""><br class=""></div><div class="">I also think you forgot to turn off your caps lock.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Dave</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 4:33 PM, John Pratt <<a href="mailto:jprattx@gmail.com" class="">jprattx@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">OK BUT WHEN YOU CHANGE THE LANGUAGE YOU MIGHT ALSO CHANGE THE EDITOR.<div class="">WE AREN'T TO BE HELD HOSTAGE BY APPLE'S INTELLECTUAL PROPERTY OBSESSIONS</div><div class="">AND GREED.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Aug 31, 2017 at 5:17 PM, Dave DeLong <span dir="ltr" class=""><<a href="mailto:delong@apple.com" target="_blank" class="">delong@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 3:58 PM, David Sweeris <<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</a>> wrote:</div><br class="m_341236304613612735Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_341236304613612735Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" 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></div></blockquote><br class=""></div><div class="">New-comers from where? I've met more than one mathematician or physicist who claims they can't code because the syntax isn't what they're used to. People with different backgrounds can and do have vastly different ideas about what constitutes an intuitive syntax for any given semantic (which why I disagree with the notion that having more than one spelling for stuff is inherently bad).</div></div></div></blockquote><br class=""></div></span><div class="">Thatâs a fair point, which IMO reinforces the notion that changes like this should be an editor-level feature, and not a code-level feature.</div><div class=""><br class=""></div><div class="">An editor can reformat code (using a font with bazillions of ligatures or whatever) in was that you wouldnât want to necessarily âhard codeâ.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Dave</div></font></span></div></blockquote></div><br class=""></div>
</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></body></html>