Robert: image literals and color literals are very similar to what I am talking about. Matrix literal? Array data table literal? That's what I am talking about
On Aug 29, 2017, at 8:24 PM, Robert Bennett <[email protected]> wrote: But the question is, why does this need to affect the code base? 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 output. 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. On Aug 29, 2017, at 3:38 PM, John Pratt via swift-evolution < [email protected]> wrote: The case I am making is that matrix multiplication would greatly benefit. If by typing "matrix()" a real algebra matrix popped out of code with multiple columns spanning multiple rows of text, wouldn't that be a major improvement for everyone who does math or graphics? There are a lot of these things. Graphical elements acting as code can do much more than plain text formatting of any programming language's syntax. On Tue, Aug 29, 2017 at 1:38 PM, Adrian Zubarev via swift-evolution < [email protected]> wrote: > I still would prefer ligature fonts (Fira-Code). All these complicated > characters might be good and so but remeber there are more than one > keyboard layout on this planet, some of those are far more complicated than > the English keyboard layout. Even I struggle sometimes with simple {} and > [] because these characters are not visible on my German keyboard layout at > all. > > -- > Adrian Zubarev > Sent with Airmail > > Am 29. August 2017 um 18:27:05, Félix Cloutier via swift-evolution ( > [email protected]) schrieb: > >> If all the hard symbols are automatically converted by the editor, why >> can't the editor show you a "pretty" view and save as "regular" text? Why >> does it need compiler involvement if the problem can entirely be addressed >> in UI space? >> >> Le 29 août 2017 à 06:14, John Pratt via swift-evolution < >> [email protected]> a écrit : >> >> Hi Chris: Please read the article that I originally posted and mailed to >> the Swift team >> before shooting down what I said: >> >> http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf >> >> Alan Kay’s FONC project rewrote entire projects in far less code by >> using symbols in the Maru and Nile programming languages. Alan Kay, as >> you know, >> is the father of Smalltalk. Unicode symbols can be very powerful. >> >> >> >> >> >> >> On Aug 29, 2017, at 12:28 AM, Chris Lattner <[email protected]> wrote: >> >> >> On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution < >> [email protected]> wrote: >> >> I think the editor would recognize that "<==“ was just >> typed and replace it with the unicode character ≤ immediately. >> >> Likewise, x^2 would be recognized and turned into x with 2 in superscript. >> >> As for how the UI would work for other types of symbols, >> there are all kinds of techniques for that. That is a UI issue, >> for a UI design team to address. XCode’s code completion is just one >> example of how UI can manage input issues. >> >> >> There is no reason to change the language to enable this. Editors could >> do this automatically. Alternatively, you could just use a programming >> font with ligatures for operators, see e.g.: >> https://medium.com/larsenwork-andreas-larsen/ligatures-codin >> g-fonts-5375ab47ef8e >> https://github.com/tonsky/FiraCode >> https://www.hanselman.com/blog/MonospacedProgrammingFontsWit >> hLigatures.aspx >> >> -Chris >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
