<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=""><blockquote type="cite" class="">On Aug 29, 2017, at 8:25 PM, Robert Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><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="">But the question is, why does this need to affect the code base?</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="">In the article you attached, they mention the antiquated one-line calculator display. The issue with that display is not the data stored in the calculator; it’s the display itself. An upgrade to (say) a Texas Instruments Inspire or whatever the newest TI calculator is (in my day we used an 83 or 84) only changes the display of the data; after all, you input that data will old fashioned buttons as well. The calculator isn’t doing any magic with the data itself in order to display that. If you want nicely formatted fractions, square roots, or matrices, go to WolframAlpha and type in your expression in ascii; you’ll see nicely formatted<span class="Apple-converted-space"> </span><span style="background-color: rgba(255, 255, 255, 0);" class="">output.</span></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="">Which is all to say, if you want pretty graphics in your code, all you need is a better front end. The backend can — and in absence of a better argument, should — remain unchanged.</div></div></blockquote></div><br class=""><div class="">Heck, we have a bit of this already, when you consider things like Xcode’s image literals. Said literals can also illustrate some of the dangers of going too far with fanciness in the text editor, as anyone can attest who’s named a graphic “info” and then had it auto-complete every time they wrote a closure containing the “in” keyword followed by a carriage return.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>