Support unicode characters for operators

[ahmadsalim]

We already support Unicode for identifiers, this would allow defining operators as Unicode too. There should probably be a flag in the future to disable Unicode support entirely (but that will take some time to implement, where this was a one-liner).

[edwinb]

I don't want to support unicode operators for several reasons:

• It's hard to type (this is important if you're using someone else's code, for example). I know various editors have their own input methods, but you have to know what they are.
• Not every piece of software easily supports it. It doesn't render properly on my phone email client, for example, occasionally messes up the terminal I run my irc client in, doesn't always render properly in my browser, etc. All of these are things I can fix but to have to do so as a barrier to entry to using a programming language doesn't seem to be a good idea to me.
• Even if we leave it out of the standard library (which we will in any case!) as soon as people start using it in their library code, others have to deal with it.
• Too many characters look too similar. We had enough trouble with confusion between 0 and O without worrying about all the different kinds of colons and brackets.
• There seems to be a tendency to go over the top with use of Unicode. For example, using sharp and flat for delay and force (or is it the other way around?) in Agda seems gratuitous. I really don't want to encourage this sort of thing, when words are often better.

I know that used with care it can make things look pretty. But so can lhs2TeX. And I'm sure that in a few years time things will be different and software will cope better and it will make sense to revisit this. For now, however, I would prefer not to allow arbitrary unicode symbols in operators.

(Aside: There could even be an argument that allowing arbitrary operators is going a bit far...)

On another note (from an irc comment): Just because people might want a feature doesn't necessarily make it a good idea to support that feature. It's important to think about the implications of that feature, how it might interact with other features, what it allows, what it prevents, and so on.

We do need Unicode support in Char and String, of course. Better to focus on that first.

This seems like an instance of Wadler's Law (http://www.haskell.org/haskellwiki/Wadler%27s_Law) in action.

[ahmadsalim]

I thought this was highly uncontroversial and it was a simple addition, so I thought why not just add it.
I guess you are right, that it might be an issue and as always the decision is yours.

In any way, I also fixed the eol to correctly handle unicode characters. Do you want that addition in a separate pull request?

[LeifW]

I'd think I'd be for this, but I don't really use unicode operators in code I intend on sharing with other people. I think the unicode glyphs that look like their existing ascii-art equivalents are unambiguous enough: http://www.scala-lang.org/old/node/4723
Even introducing a unicode character into a comment in Idris source broke the build for a number of people semi-recently, though...

[LeifW]

Generally, I've been typing ascii-art, and if I want to see the unicode characters, I use a transformation on my view of the file, like https:/vim-scripts/Haskell-Conceal/blob/master/after/syntax/haskell.vim#L35

[ahmadsalim]

3.5 years later, is this something we should reconsider having again now?
It should be possible to readd support if we wanted to.

[david-christiansen]

No, I still think @edwinb's reasons hold.