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@swift.org(mailto:swift-evolution@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@swift.org(mailto:swift-evolution@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@nondot.org(mailto:clattner@nondot.org)> wrote:
> >
> > > On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution <swift-evolution@swift.org(mailto:swift-evolution@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.:
> > Ligatures & Coding. What they can, can’t and shouldn’t do | by Andreas Larsen | Larsenwork | Medium
> > GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures
> > https://www.hanselman.com/blog/MonospacedProgrammingFontsWithLigatures.aspx
> >
> > -Chris
> >
> >
> >
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution
I agree with what you said and I wonder myself if it is possible at this
time for Swift to do what I mentioned in that article, given the current
roadmap.
Everyone would have to rewrite the agenda of Swift 5 to incorporate
most of what I was talking about. Additionally, Swift's
syntax and XCode would begin to overlap. It would definitely require a "smart
editor," but then I also think that all terminals should be smart likewise.
The distinction between code and code editor would become less clear.
This is probably something that needs to be tested, as a proof
of concept, before a lot of people are ready to accept it. But I am glad that
people are at least recognizing what I am talking about on this list, that unicode
symbols could be used.
I saw the beginning of crowdfunding. The website I founded had one of our
users actually coin the word. People at Kickstarter were able to swoop in and get
huge investors because the proof of concept was there for 4 years. In other words:
no one thinks anything is going to work until it’s there. But it still might work.
-John
···
On Aug 29, 2017, at 11:33 PM, Chris Lattner <clattner@nondot.org> wrote:
On Aug 29, 2017, at 6:13 AM, John Pratt <jprattx@gmail.com <mailto:jprattx@gmail.com>> wrote:
Hi Chris: Please read the article that I originally posted and mailed to the Swift team
before shooting down what I said:
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.
Ok John, let me approach this from a different direction:
I’m not saying that doing such a thing would have zero value. Far from it, it could be an interesting research project for someone focusing on programmer productivity to investigate.
My primary objections (compared to doing nothing: recommending that folks who care use a ligature font) are:
a) Going down such a path has a lot of possible disadvantages: it could lead to forking the community (multiple ways of spelling the same thing), it cold make it harder to write code, it could lead to “requiring” smart editors, etc. The threshold for acceptance is not just “potentially interesting”, but something like this must “far outweight any downsides”. That criteria isn’t clear to me.
b) If you clear that hurdle, you need to clear the opportunity cost hurdle. Why is addressing this potential for improvement more important than the other potential areas for improvement? Why is this critical to address now? How does this align with the Swift 5 goals?
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.
XCode is not just one of many editors to edit Swift you asshole.
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.
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.
John.
···
On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution <swift-evolution@swift.org> wrote:
On Thu, Aug 31, 2017 at 12:44 PM, John Pratt <jprattx@gmail.com <mailto:jprattx@gmail.com>> wrote:
On Aug 31, 2017, at 11:27 AM, Taylor Swift <kelvin13ma@gmail.com <mailto:kelvin13ma@gmail.com>> wrote:
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.
On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
A few thoughts:
1) I would like to see Xcode gain a couple more literal types using the same strategy it does for Image and Color literals
2) I would LOVE to see simple equation typesetting in Xcode
(Those two are mostly up to the Xcode team as opposed to swift, I suppose)
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.
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.
5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t 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 ‘≤’).
6) My recommendations for typing symbols would be:
a) Choose a subset of useful and well-known symbols instead of every symbol
b) Allow autocomplete on those symbols by name
c) Optionally choose a little-used guardian character to start the names of symbols (to avoid accidental autocompletion).
Thanks,
Jon
On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.
Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.
Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?
Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.
I have written my own library with this (it was one of the first things I wrote in swift) and there are several others available online.
OK, so link to them, and get the various parties to agree on using one definition instead of several.
So instead of “Nothing is stopping you from doing this yourself” it is “Nothing is stopping you from doing this and then getting the entire internet to somehow agree on the one true version”… That is a much larger goal.
The issue is that if I want to include another framework, and that framework has also defined it (or more likely relies on another framework that defines it) then swift gets upset about the multiple definitions. I really want to rely on those libraries, but if it makes my own framework have a danger of conflicts with other libraries then it will stop adoption of my framework as a result.
This hasn't stopped a number of others from relying on types they've defined, like the Result type, for example.
Things like Result can be differentiated by the module name in case of conflict. That isn’t possible with operators.
Also, there are now two versions of AlamoFire which need to be kept in sync depending on which Result type they use.
It seems extra ridiculous because those definitions are all basically identical. Do you see the issue?
There's a difference of expectations here as to the purpose of the swift-evolution list. It's not about growing personal preferences of how to achieve that which is already available and possible to do today.
I view lack of ‘≤’ as a symptom of a much larger issue.
I know I have a different way of looking at things than most people on this list (I mainly work as a designer and teacher), but little details like this really affect the experience of using Swift, especially for beginning programmers. One of the things that drew me to Swift was the level of thought that was clearly put into this sort of thing over the first 2 versions. Starting with version 3, Swift has been growing much less pleasant to use over time, which makes me really sad. I attribute that mainly to focusing only on big structural things (and functionality), and ignoring the little “insignificant” details which actually make or break the experience.
The niceties just aren’t important enough to devote any time or thought to. “Sure that would be nice, but we could use that time to do ____”. It is funny, because people spend way more time writing up arguments for why we shouldn’t think about these things (because of lack of time) than it took to write the 6 lines of code to do them.
Every time I bring up an issue like this I get a couple of messages telling me that maybe Swift just isn’t for me, and that I should go find another language instead. I am the only one of my friends/colleagues left on this list, so maybe I will eventually do that. But shouldn’t Swift be a language that works for people like me too? I don’t think it should be only for hard-core compiler engineers. I think this list would benefit from a multitude of voices with different viewpoints, but it seems to view as irrelevant and vocally chases away any viewpoint/mindset which doesn’t match the dominant one.
Thanks,
Jon
···
On Aug 31, 2017, at 8:56 AM, Alex Blewitt <alblue@apple.com> wrote:
The issue is that if I want to include another framework, and that framework has also defined it (or more likely relies on another framework that defines it) then swift gets upset about the multiple definitions. I really want to rely on those libraries, but if it makes my own framework have a danger of conflicts with other libraries then it will stop adoption of my framework as a result.
This hasn't stopped a number of others from relying on types they've defined, like the Result type, for example.
Things like Result can be differentiated by the module name in case of conflict. That isn’t possible with operators.
Also, there are now two versions of AlamoFire which need to be kept in sync depending on which Result type they use.
There’s exactly one version of Alamofire. Anyone maintaining a fork that uses another Result type does so on their own time without support from the Alamofire project itself.
That said, this is a major pain in the ass. About once a year we get a request from someone for us to use the antitypical Result type instead of our own. We reject it because we don’t want dependencies in such a highly used library. So users have to go through the trouble of either bridging between the two types or using some fork. It’s further complicated by the fact that in Alamofire 4 / Swift 3 we switched to Result<T> instead of Result<T, E>, since we deal with generic Errors from the underlying URLSession APIs most of the time. That makes the bridging that much more complicated. But manual differentiation can be tricky to make work, there were some unexpected gotchas.
So, do the 500,000+ combined installs of Alamofire and Result qualify this type for inclusion in the standard library yet?
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@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@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@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:
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@nondot.org> wrote:
On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution < >> swift-evolution@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.
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@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@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@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@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:
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@nondot.org> wrote:
On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution <swift-evolution@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.
However pretty printing things like matrices get handled, if that isn't simply part of the OS's text handling facilities, every "smart" editor will handle it differently (like different HTML rendering engines, except without the common HTML spec) and the "dumb" editors will show something that's shockingly different. It really seems to me that getting good, consistent support for "multi-line lines" in regular text editors will probably take a new OS which has that functionality baked-in its APIs at a low enough level that there isn't a way to not support it without just completely rolling your own text system (I suppose removing and replacing the existing APIs would work, too, but from a certain PoV that essentially is a new OS). In particular, if rows are no longer fixed-height, you've decoupled the cursor's logical position from its on-screen position... apps that were written/compiled before pretty print came into the API would render everything after an extra tall line at the wrong y position.
I think getting easy unicode input is probably doable for the big three OSs, though, especially if the USB consortium would release a unicode-aware HID spec.
- Dave Sweeris
···
On Aug 30, 2017, at 8:21 AM, John Pratt via swift-evolution <swift-evolution@swift.org> wrote:
I agree with what you said and I wonder myself if it is possible at this
time for Swift to do what I mentioned in that article, given the current
roadmap.
Everyone would have to rewrite the agenda of Swift 5 to incorporate
most of what I was talking about. Additionally, Swift's
syntax and XCode would begin to overlap. It would definitely require a "smart
editor," but then I also think that all terminals should be smart likewise.
The distinction between code and code editor would become less clear.
This is a clear violation of Swift’s code of conduct. We will not tolerate this kind of toxic interaction on or off the mailing lists.
Ted
···
On Aug 31, 2017, at 1:13 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:
On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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.
On Thu, Aug 31, 2017 at 12:44 PM, John Pratt <jprattx@gmail.com <mailto:jprattx@gmail.com>> wrote:
XCode is not just one of many editors to edit Swift you asshole.
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.
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)
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: https://medium.com/@andre_videla/elegant-swift-ec702fc84f11
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.
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.
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.
Another programming language inspired by Agda, Idris, completely ditched unicode and mixfix operator for reasons exposed here:
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 `check Γ ⊢ t ∈ a` (from the definition `check _ ⊢ _ ∈ _` 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.
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?
On 31 Aug 2017, at 22:13, John McCall via swift-evolution <swift-evolution@swift.org> wrote:
On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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.
On Thu, Aug 31, 2017 at 12:44 PM, John Pratt <jprattx@gmail.com <mailto:jprattx@gmail.com>> wrote:
XCode is not just one of many editors to edit Swift you asshole.
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.
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.
John.
On Aug 31, 2017, at 11:27 AM, Taylor Swift <kelvin13ma@gmail.com <mailto:kelvin13ma@gmail.com>> wrote:
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.
On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
A few thoughts:
1) I would like to see Xcode gain a couple more literal types using the same strategy it does for Image and Color literals
2) I would LOVE to see simple equation typesetting in Xcode
(Those two are mostly up to the Xcode team as opposed to swift, I suppose)
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.
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.
5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t 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 ‘≤’).
6) My recommendations for typing symbols would be:
a) Choose a subset of useful and well-known symbols instead of every symbol
b) Allow autocomplete on those symbols by name
c) Optionally choose a little-used guardian character to start the names of symbols (to avoid accidental autocompletion).
Thanks,
Jon
On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.
Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.
Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?
Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.
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.
Charles
···
On Aug 29, 2017, at 8:25 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org> 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.
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
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.
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 Aug 29, 2017, at 8:24 PM, Robert Bennett <rltbennett@icloud.com> wrote:
On Aug 29, 2017, at 3:38 PM, John Pratt via swift-evolution < swift-evolution@swift.org> wrote:
On Tue, Aug 29, 2017 at 1:38 PM, Adrian Zubarev via swift-evolution < swift-evolution@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@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@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:
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@nondot.org> wrote:
On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution < >> swift-evolution@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.
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).
- Dave Sweeris
···
On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution <swift-evolution@swift.org> wrote:
Just a side observation…
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.
On the other hand, while using inefficient matrix notation may be more verbose, it is consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.
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.
On the other hand, while using inefficient matrix notation may be more verbose, it is consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.
Dave
···
On Aug 31, 2017, at 3:13 PM, André Videla via swift-evolution <swift-evolution@swift.org> wrote:
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)
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: https://medium.com/@andre_videla/elegant-swift-ec702fc84f11
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.
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.
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.
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 `check Γ ⊢ t ∈ a` (from the definition `check _ ⊢ _ ∈ _` 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.
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?
On 31 Aug 2017, at 22:13, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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.
On Thu, Aug 31, 2017 at 12:44 PM, John Pratt <jprattx@gmail.com <mailto:jprattx@gmail.com>> wrote:
XCode is not just one of many editors to edit Swift you asshole.
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.
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.
John.
On Aug 31, 2017, at 11:27 AM, Taylor Swift <kelvin13ma@gmail.com <mailto:kelvin13ma@gmail.com>> wrote:
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.
On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
A few thoughts:
1) I would like to see Xcode gain a couple more literal types using the same strategy it does for Image and Color literals
2) I would LOVE to see simple equation typesetting in Xcode
(Those two are mostly up to the Xcode team as opposed to swift, I suppose)
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.
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.
5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t 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 ‘≤’).
6) My recommendations for typing symbols would be:
a) Choose a subset of useful and well-known symbols instead of every symbol
b) Allow autocomplete on those symbols by name
c) Optionally choose a little-used guardian character to start the names of symbols (to avoid accidental autocompletion).
Thanks,
Jon
On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.
Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.
Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?
Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.
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.
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”.
Dave
···
On Aug 31, 2017, at 3:58 PM, David Sweeris <davesweeris@mac.com> wrote:
On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Just a side observation…
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.
On the other hand, while using inefficient matrix notation may be more verbose, it is consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.
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).
To clarify, you're suggesting we do something like this? @prettyprint(prefix operator "Σ", /*probably some CSS or something for telling the editor where to position the arguments relative to the operator, whether they're rendered with subscript vs superscript vs normal, etc */)
func sum <T: Numeric, S: Sequence> (indicies: S, term: (S.Element) -> T) -> T {
return indicies.reduce(0) { $0 + term($1) }
}
Technically speaking, yeah, sure, such a system could be made to work. I don't see it getting much support outside of Xcode, though, unless you can convince other languages to adopt the same convention. We'd want people's choice of display style to be driven by personal preference, not whether they can integrate Xcode into their workflow. Speaking of workflows, how far from "plain text" do you think we can get before people start thinking that you need a mac running Xcode to program in Swift?
- Dave Sweeris
···
On Aug 31, 2017, at 3:17 PM, Dave DeLong <delong@apple.com> wrote:
On Aug 31, 2017, at 3:58 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Just a side observation…
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.
On the other hand, while using inefficient matrix notation may be more verbose, it is consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.
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).
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.
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”.
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.
I also think you forgot to turn off your caps lock.
Cheers,
Dave
···
On Aug 31, 2017, at 4:33 PM, John Pratt <jprattx@gmail.com> wrote:
OK BUT WHEN YOU CHANGE THE LANGUAGE YOU MIGHT ALSO CHANGE THE EDITOR.
WE AREN'T TO BE HELD HOSTAGE BY APPLE'S INTELLECTUAL PROPERTY OBSESSIONS
AND GREED.
On Thu, Aug 31, 2017 at 5:17 PM, Dave DeLong <delong@apple.com <mailto:delong@apple.com>> wrote:
On Aug 31, 2017, at 3:58 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Just a side observation…
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.
On the other hand, while using inefficient matrix notation may be more verbose, it is consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.
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).
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.
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”.
Perhaps… I’m fully admitting up-front that this is all really hand-wavy and we’re probably veering a bit off-topic, since this is getting more in to “editor-evolution” rather than “swift-evolution”.
But yes, if an editor had some sort of intrinsic knowledge about the purpose of a line of code, then it could visually “rewrite” a summation function using a Σ. Or if it knew about matrix types, perhaps it could render the matrix in the 2D format that is standard to matrix notation. Or it could replace UIImage(named: “someConstant”) with the rendered image literal, without actually requiring the explicit underlying image literal syntax.
A grossly simplified comparison is that good markdown editors don’t just show the plaintext for the markdown you’re writing, but will also `stylize` *code* _correctly_ **as** *`you write it`*.
Dave
···
On Aug 31, 2017, at 5:45 PM, David Sweeris <davesweeris@mac.com> wrote:
On Aug 31, 2017, at 3:17 PM, Dave DeLong <delong@apple.com <mailto:delong@apple.com>> wrote:
On Aug 31, 2017, at 3:58 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Just a side observation…
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.
On the other hand, while using inefficient matrix notation may be more verbose, it is consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.
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).
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.
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”.
To clarify, you're suggesting we do something like this? @prettyprint(prefix operator "Σ", /*probably some CSS or something for telling the editor where to position the arguments relative to the operator, whether they're rendered with subscript vs superscript vs normal, etc */)
func sum <T: Numeric, S: Sequence> (indicies: S, term: (S.Element) -> T) -> T {
return indicies.reduce(0) { $0 + term($1) }
}
Technically speaking, yeah, sure, such a system could be made to work. I don't see it getting much support outside of Xcode, though, unless you can convince other languages to adopt the same convention. We'd want people's choice of display style to be driven by personal preference, not whether they can integrate Xcode into their workflow. Speaking of workflows, how far from "plain text" do you think we can get before people start thinking that you need a mac running Xcode to program in Swift?
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
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.
My 2c.
···
On Aug 31, 2017, at 7:14 PM, Dave DeLong via swift-evolution <swift-evolution@swift.org> wrote:
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.
I also think you forgot to turn off your caps lock.
Cheers,
Dave
On Aug 31, 2017, at 4:33 PM, John Pratt <jprattx@gmail.com> wrote:
OK BUT WHEN YOU CHANGE THE LANGUAGE YOU MIGHT ALSO CHANGE THE EDITOR.
WE AREN'T TO BE HELD HOSTAGE BY APPLE'S INTELLECTUAL PROPERTY OBSESSIONS
AND GREED.
On Thu, Aug 31, 2017 at 5:17 PM, Dave DeLong <delong@apple.com> wrote:
On Aug 31, 2017, at 3:58 PM, David Sweeris <davesweeris@mac.com> wrote:
On Aug 31, 2017, at 2:51 PM, Dave DeLong via swift-evolution <swift-evolution@swift.org> wrote:
Just a side observation…
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.
On the other hand, while using inefficient matrix notation may be more verbose, it is consistent with the other notation used in programming, which means it is more easily understandable for new-comers to the code.
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).
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.
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”.
To be fair, that’s probably the case. The project is quite extreme (an implementation of System F, I think Robert Widmann did one in Swift as well), and I can’t understand it either regardless of syntax. But the point of the example still stands: To show how extreme you can go with unicode. And from it, spark some discussion.
I agree that using unicode syntax is a higher barrier for entry, which goes against the goal of swift to be an easy to learn language.
Nevertheless, I disagree with your matrix example. We already use things like `+` for “things that we can add together` whatever `add` might mean. So the same operator is used for (Int, Int) -> Int as for (Double, Double) -> Double. I do not think it’s a stretch to expect users to know that matrices are “addable” togethers. Moreover, I would expect that a matrix API provides both an infix operator as well as a named function for manipulating matrices.
Furthermore, I would argue that using `+` for matrices is more consistent than the current definition of `+`.
Indeed, the operator `+` is both used for combining numbers and combining arrays/strings. The inconsistency comes from the fact that it is expected that `+` is a commutative operator, but concatenation is not a commutative operation. Therefore the semantics of `+` varies depending on the types that it’s used on. And, in my opinion, this inconsistency is to be avoided when dealing with operators. Not to mention that nothing prevent a library to override `+` with any nonsensical behaviour.
Something I could imagine is deprecate operator overloading and constrain them to a single Type. For example, the operator `+` could be constrained to the protocol `Addable` and has the signature `infix func + (Self, Self) -> Self` and is commutative. Similarly, we could have a protocol `Concatenable` which has its own operator (e.g.: ++ ) and is not commutative. (those are secretely `CommutativeMonoid` and `Monoid`). This would allow different operators to represent different semantics and have them (loosely) enforced, so that nobody can declare something unexpected like `func + (Int, Array) -> ()`.
In conclusion, I think that the current state of operators should be improved in some way, regardless of better support for unicode or not. I realise my stance is quite extreme but I think that it is valuable to talk about it.
···
On 31 Aug 2017, at 23:50, Dave DeLong <delong@apple.com> wrote:
wonder if I need to go back to school for a degree in Math just to understand what’s going on.
