New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support unicode characters for operators #694

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@ahmadsalim
Contributor

ahmadsalim commented Nov 30, 2013

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

This comment has been minimized.

Contributor

edwinb commented Nov 30, 2013

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.

@edwinb edwinb closed this Nov 30, 2013

@ahmadsalim ahmadsalim deleted the ahmadsalim:feature/unicode branch Nov 30, 2013

@ahmadsalim

This comment has been minimized.

Contributor

ahmadsalim commented Nov 30, 2013

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

This comment has been minimized.

Contributor

LeifW commented Nov 30, 2013

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

This comment has been minimized.

Contributor

LeifW commented Nov 30, 2013

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://github.com/vim-scripts/Haskell-Conceal/blob/master/after/syntax/haskell.vim#L35

mmhat pushed a commit to mmhat/Idris-dev that referenced this pull request Jun 13, 2014

@ahmadsalim

This comment has been minimized.

Contributor

ahmadsalim commented Mar 16, 2017

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

This comment has been minimized.

Contributor

david-christiansen commented Mar 16, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment