Wow, that's kind of cute: {-# LANGUAGE UnicodeSyntax #-} (＊) = (*) (／) = (/) 公式 高 中 低=高＊中＊低／整數 整數 = 123 Oddly, if I change the order of these definitions I get syntax errors. Very mysterious. Nice how it knows that ＊ is a symbol, but I'm not sure how I'm supposed to name a type. It certainly spells the end of of camelCase arguments though, and can take single-character variable names to dizzying new heights :) I suppose number literals can't be overridden though. Not to mention ＝ and （）.
It's not just one's editor (I use emacs, and it's actually not that hard to type a decent subset of interesting Unicode characters in emacs with the tex input mode), but readability. The ASCII characters are universal and easily recognized (assuming you have a decent monochrome font); having to notice potentially significant differences involving diacritics alone (not to mention all the various mathematical symbols) in identifiers would drive me mad. It's the same reason we try to limit lines of code to ~80 characters -- our editors are *capable* of more, sure, but are we?
Unicode identifiers are fun but this is a good point. The line has to
be somewhere, so it might as well be in the historical position unless
there are widely agreed on benefits to moving it.
On Wed, Jan 13, 2010 at 10:45 PM, Colin Paul Adams
My wife is Chinese. When she was learning pinyin as a child, she asked her father for help with some homework. He replied that he didn't understand them.
But that's all kind of beside the point because you already need to learn quite a bit of specialized knowledge to be writing in haskell in the first place. It's real hard to get to that stage without already recognizing ascii. If the problem was just pinyin and not latin letters in general, then most Taiwanese wouldn't understand it either.