[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan Hull]

If someone wants to write their variable names in Spanish or Japanese, they should be able to.  That is one of the main reasons for including unicode.  (Note it might make it more difficult for me to read, but it makes it easier for them and their team).

If a group of mathematicians find it useful to write code that looks like the language they use in their everyday life, why do we need to stop them?  It doesn’t have to be useful to everyone to be incredibly useful (and communicative) for them.

And it’s not just math. I was able to use custom operators in Swift to mimic the standard PEG grammar (with only a few small differences), and it is incredibly useful.  The ability to transcribe a grammar directly from a research paper without having to translate to another (much less clear) language is enormously beneficial to me.  I am able to see the structure directly instead of having to “read” it from code (and translate back to my working language) the way you have to in most languages. That results in being able to put together much more complicated and full featured systems and still be able to understand them better at a glance.  That is actually one of the main reasons I have been using Swift over Objective C.


> It's more practical to make breaking changes now and introduce the "right set" (that is, a standards-based set of mathematical operators) at a future date, than to justify keeping things as is and removing operators at a future date.
Define practical. How is breaking shipping code to solve a theoretical problem practical?  I have yet to see any evidence that the current system is actually causing ANY real world problems.

You can break EVERYTHING now, or break only a small subset of that (which is the part which most people probably aren’t using anyway) when you know the standards for certain. I don’t understand the mindset that breaking more is better.  This is one of those cases, where if the eventual standard breaks too many things, then you have chosen your standard incorrectly, because it doesn’t reflect reality.  The market will speak about what is useful.

Why not say: “These are definitely going to be identifiers. These are definitely going to be operators.  Everything else is currently undefined and will stay where it is, but may change in the future to match X spec”.  I don’t see how that is any more harmful to the growth of Swift, and it is certainly less harmful to the rest of us while we wait.

> Beginning with Swift 4, there will be a major push to ensure that backwards
> compatibility with existing code is not broken. It will be possible to
> expand the operator character set, but very difficult to shrink it.
IMO that point has been crossed already. Swift 3 was for all the breaking changes, and now for Swift 4 there is a much higher barrier. We are past the point of breaking everything for the sake of breaking them because adding is easier.

Honestly, there are a lot of helpful improvements in Swift 3, but I would be hard pressed to find any of the panicked “we have to break it now or we won’t be able to later” changes that were made among them.  Those things are just broken, waiting for someone to fix them in an undefined future time.  Given that I am still waiting for Apple to fix bugs from Panther, I am not holding my breath.

> Personally, a *very* limited cherrypicking might be OK, on the
> understanding that it must be done with very stringent inclusion criteria.
> However, it's specifically the set algebra operators that I have the
> greatest objection to cherrypicking:
> 
> * Each of these operators has a specific meaning; it is an anti-goal to
> support repurposing the union operator for any other purpose than forming a
> union of two sets, for instance.
There are many different branches of math which use symbols in different ways.  Higher order logic, for instance, uses the union symbol as an operation (which is not the union of two sets). I have an old book on computer chip design which uses the union symbol as a way to optimally place logic gates.   

I wrote a program (just for myself) that helped me solve a math problem in graph theory that I had been working on for 10 years.  10 years… and the program helped me solve it in a matter of days.  If I find that symbol useful for my computations, but it isn’t the union of two sets, why is that a problem?

There are also many other fields besides math which use symbols for short hand.  The ‘+’ symbol is used for addition, but it is also used for concatenation of Strings.

My point is that as much as you think you know my goals or context, you don’t.  It is an anti-goal for us to be the language style police… restricting people’s expression because we don’t understand their context, and limiting them to problem spaces which we find interesting. In my experience, that sort of thing is the root of all evil (and the root of bad UI/UX).

I used to work on a language which catered to content matter experts. They were horrible programmers, and most of the code they wrote would give you nightmares (the UI was typically pretty bad as well).  But, you know what, it was beautiful… They were able to cobble together something for themselves, and even if nobody else used it, they had made something which improved their lives. They made things which helped their businesses.  They made things which let them run scientific experiments.  They made things that didn’t have a big enough market to interest professional programmers.  They made things which they were proud of.

To say things like: "This is the only possible purpose for this symbol" is to ignore entire worlds beyond your experience.  There are lots of little communities which use things in a way the mainstream does not.

Symbols should be operators. Ambiguous things should be marked as ambiguous with a warning that they may shift in the future as we disambiguate.  I actually have an idea how to solve this, but I will write it in another email.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161019/7abf5a66/attachment.html>