Reconsider identifiers

Is it really a good idea to have that freedom on identifiers (ID)?

Some identifiers that I believe are good to have:

• abc, name1 and such (C-style) should be ID (Latin, Arabic digits)
• sin² should be valid (mix Latin with unicode Arabic digits)
• αθηνα should be valid (Greek)
• ΩS¹, sinβ should be a valid (mix Greek with Latin and unicode digits)
• +, /, -, * should be valid (operators) but we may reserve a few as keywords like @ (like Java), # (?) or % (like Idris)
• ⁄, ⌀, ⁒, ·, ÷ should be valid (unicode operators)
• ::, :<, >>= are valid (several operators)
• +₁, +₂, ÷₂, *‘ should be valid (operators followed by unicode digits)

Something that are currently ID, I think are confusing:

• +1 – looks like λx. x + 1. Similarly 1+
• call/cc looks like call / cc to people w/o scheme experience. We may call similar function callCC, shiftReset
• suc-suc – because we know suc is not a “number” so we know it’s not suc - suc, but if it’s o-o, it’s less clear. It can be o - o.
• a+b – even worse.
• a+b=c – also valid in Agda. EVEN worse.
• +-comm – commonly used in Agda. In Idris it’s called plusCommutative iirc. I think the Idris name is acceptable. I’m not sure though.

I am thinking about a criterion that is similar to Haskell:

• Let \a denote Latin/Greek/CJK/Russian alphabets
• Let \o denote operators (unicode inclusive)
• Let \u denote unicode superscript and subscript (numeric and alphabetic)
• Let \d denote digits (unicode inclusive, exclude super/subscript)

Then \a[\a\d]*\u* | \o+\u* basically describes what I wanted. This will cause some renaming in the current stdlib.

[imkiva]

In general, I am fine with current identifiers, that is, composing IDs from a sequence of visually visible characters. I don’t like putting restrictions on identifiers (because remembering these rules is also a burden to users) except those that significantly improve readability:

• no whitespaces inside (like mixfix operators)
• no leading numbers (looks like literal suffixes in other languages: 114514ULL)

And there are other reasons:

• +-comm looks better than plusComm because for humans (at least for me), splitting by the hyphen - is easier than splitting by any upper-case alphabet. I know you can choose plus_comm but the underlines are less beautiful – they are not centered.
• IDs like a+b=c, +1 and a+b=b+a do not actually make code harder to understand. Because the formatter always produces a + b = b + a if it is really an expression.

[wsx-ucb]

I think as long as we disallow white-spaces in identifiers, I’m totally fine 😄 If in addition we enforce white-space in between identifiers, then having the current naming freedom also induce no ambiguity (and arguably still easy to parse by human). While probably it is better to use addComm over a+b=b+a, naming proof terms of more complicated relation with the white-space collapsing, symbolic style can be easier and clearer in some situations. Naming things is already hard enough for us programmers, and I think having a wider range of naming style to choose can help alleviate the burden a bit.