[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[John Pratt]

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 <rltbennett at icloud.com> 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 <
swift-evolution at swift.org> 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 <
swift-evolution at swift.org> 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 (
> swift-evolution at swift.org) 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 <
>> swift-evolution at swift.org> 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 <clattner at nondot.org> wrote:
>>
>>
>> On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution <
>> swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170830/f3a30d6d/attachment.html>