Wenyan: Consider using identifier names directly

[yejingchen]

Currently Chinese identifier names are transformed into pinyin, which might cause a redefinition if the same pinyin is also defined using wenyan, like this:

Both ES2015 and Python 3 support Unicode identifier names, there shouldn't be much problem using it directly.

[abnernat]

Or set a more sophisticate variable naming machanism. Chinese include a vast amount of characters, simply difference words with its pronouciation and tone is not enough. Maybe do it like url encode function?

[LingDong-]

Hi there,

Thanks for the Issue!

• Firstly there is actually an option to turn off the automatic Romanization. In CLI it is --roman false, in JavaScript it's parser.compile('js', input, {romanizeIdentifiers:false}). I'll probably add a GUI toggle for it on the online IDE too.

• Currently, If two different identifiers have the same pinyin, a _ character will be appended to the latter (or more _'s will be appended if name clash remains), as you see in your example (the second JIA_). So there shouldn't be any problem if you only use Chinese characters.

• Which brings us to the third line where you used the pinyin directly, and my current policy is to leave non-Chinese characters as they are. Your example made a good point, and now I'm rethinking that policy. :-P

• I'm planning to add another mechanism, as DrMerxer mentioned. Probably unicode entry points? so 「甲」 would be _u7532. But that would decrease the readability of the compiled code.

Please feel free to let me know your thoughts! Thanks.

[zhmushan]

@LingDong- we can keep "甲" in the compiled file without any modification.

[tiansh]

Prefer using Han characters directly

1. By keeping the original Han character name in compiled result, the compiled program would be able to keep best readability.
2. We just need to output the compiled result in UTF-8 encoding, so everything should work, and no one will be harmed.

So, IMO, this should be the default way to handle variable names.

In case output ASCII if needed

In case someone want to compile into ASCII source code, using U4F60U597D would be enough (which is easy to implement and works fine).

Why should it avoid pinyin

1. Han characters are not only used in Chinese. Pinyin is not the only way to romanise Han characters.
2. Characters reading in Classical Chinese may variant with part of speech, may be different to stander mandarin readings nowadays.
3. Unihan includes >80k characters, and most of them wont have a stander reading at all.

[LingDong-]

@tiansh, congrats, you've convinced me :)
I will change using original identifier names to default, and add an option to use unicode entry points.
Thanks.

[LingDong-]

This issue is now fixed:
34119f806c2e62b9543d7e692bd3bd5e9b406edd

Original identifiers are used by default in all components. GUI for optionally selecting romanization method will be added in the next GUI update.

Thanks everyone for the discussion!