Unicode dashes as "lisp'ish" alternative to hump and snake notation

[ozra]

I use this-is-an-identifier all the time in my code-bases (both in LiveScript for JS, and my home brew C++ transpiler). Seeing that Nim has such a magical feature to keep coders happy with thisIsAnIdentifer and this_is_an_identifer unification (world peace! At last!), it's a perfect candidate for introducing dash-delimiting.

The problem some have with it is the ambiguity regarding identifier-dash vs subtraction operator. For us who use it daily, that's a no-brainer - operators are always spaced. In Nim, this can be solved even better: a subtraction op is a subtraction op, the allowed dash in identifiers is instead a specific Unicode rune.

I'm working on this right now, so I do hope it can be a accepted PR when I get it working. Otherwise I'll have to add a transpilation stage, or patch Nim all the time, shudders..

This would cater to lispers, cobolers (if they're not dead), livescripters, htmlers, cssers, url-sluggers, etc. (OK the list got a bit contrived at the end, I'll give you that!)

Personally I can't live with out it.

I'd like some input on the rune to reserve for the purpose. The candidates so far are: ⋯ and —

• both make it very clear they're not subtraction signs
• both tie the identifier tightly together, even in non-spaced juxtaposition to subtraction op
• both are available in all popular mono spaced fonts I've tried in the editor

The only downside is reserving one Unicode-rune to be 'magical' in identifiers like _ and capitals, instead of verbatim, which I find perfectly reasonable. The way I see it, it's the only missing magic in the identifier-delimiter wars...

Thoughts?

[ozra]

Araq suggested rune · (see http://golang.org/src/runtime/asm_386.s) because of greater visual disambiguation vs -. I take the liberty of adding it here (from IRC).

[josephwecker]

I had almost the exact same feature request in mind and even have a mostly working branch for it that I haven't pushed yet. I was using U+2011 ‑ (non-breaking or "hard" hyphen) because it was semantically correct but was worried that it might lead to some visual confusion. I like a dot separator, but would prefer U+2027 ‧ (hyphenation point) rather than middle-dot (U+00B7) used in the asm_386 example. Funny enough, either one of these would be more technically correct than either dash-minus or even the underscore (which, before IBM's NPL language was only a word-combiner for certain Egyptian languages).

Obviously one can already use these unicode symbols- the point, as stated by @ozra is to make it automatically equivalent to underscore etc. (so I can use it freely and know that someone can interact with my libraries etc. without a problem even if their editor doesn't support easily typing the code-point).

If I have time today or tomorrow I'll push the pull request.

[dom96]

How do you plan on typing these unicode characters in?

[josephwecker]

@dom96 I personally use vim and can simply have a imap __ ‑ in my ~/.vimrc so that whenever I quickly type two underscores in a row it will replace it with (in this case) a nonbreaking hyphen. If I really want two underscores, I can just pause for a second before typing the second one. Of course, I can make it so the key mapping only applies when editing nim files. I assume most other editors have similar capabilities- but the point of this feature would be that it wouldn't matter if they didn't- it would only help those that care without bothering anyone else ;-)

also, @ozra - don't hesitate to do your own PR if you get to it before me. The time I can allocate is unpredictable.

[ozra]

Hey, @josephwecker, that sounds fucking awesome! And well thought out regarding the semantic meaning of the runes. I've just begun fiddling with the source, so need some time getting aquainted, and could put my time on fixing something else on the nim issue list instead, no point duplicating an effort. I would really appreciate that getting into the 'piler.

@dom96 - as mentioned: swiftly done in vim, and other editors. Personally, I have made my own keymap, since most programming chars are not easily accessible in the swedish layout, I'll just add 'the chosen one' to my hacker-se layout. Granted, that might not be the most common thing generally to do. Most editors allows abbreviations though. And many allow direct Unicode typing with '\uxxxx'+space. In linux you can type "ctrl+shift+u" then the Unicode point number, than space, so in linux case there's not even need for editor support (slightly cumbersome to type though). I assume the same hold for windows, mac etc., but do not know them.

[ozra]

I'll investigate font compatibility a bit more and see what I find - "working in reality" is important ;)

[dom96]

@ozra @josephwecker I'm wondering why you can't simply configure your IDE/Text Editor to replace hyphens with underscores.

[Varriount]

On the IDE side, I can add such functionality to the Sublime Text plugin.

[josephwecker]

@dom96 well, you could, but this feature request isn't to save pushing the shift-key, it's because hyphens are the correct way to combine multiple words into a single word (it would have looked funny if I had said 'shift_key' or 'shiftKey' earlier in the sentence, for example). In addition to being "correct," they look better and are more understandable. Common underscore usage and camel-cases (in all their variations) are relics from languages that prioritized subtraction (without needing surrounding spaces) over readable identifiers. I believe subtraction was more common than multi-word identifiers (and therefore deserved the optimization) for all of maybe a couple of years, several decades ago.

In other words, for me at least, the whole point is to have more readable code. I guess you could have the IDE still display a hyphen while secretly saving it as an underscore (maybe that's what you meant?) but it seems hacky and prone to weird states... If it doesn't make it into the language I would probably end up doing quick 'pre-preprocessing' script like @ozra has that converts hyphens into underscores as part of the compile process. Hacky also, but less so.

[ozra]

It can be confusing for when you do use underscores for one. And since it's the only unsupported one of the popular delimiting methods - it's almost political by now ;-)
There are basically three schools of identifier delimiting, so why not support all when Nim has this magic property of unifying those, that I haven't seen in any language before? I've been coding hump for well over 15y, not thinking about it, then I got into a project where snake was de facto. Then I realized I liked it slightly better, and tried out dash-notation - which simply is the way.
The extendibility of Nim could appeal to lispers also, and they'd like it. LiveScripters might give up iojs and turn to Nim, who knows. Ok, these are speculative at best. But it being one of the three common delimiting styles is what it is.

In any event, regarding the rune vs fonts: I tried several mono fonts in Atom and Sublime (not a very complete test), and it seems the only ones with consistent support is U+00B7 and U+2014 - the other's are out the window. Semantic or not.

@Varriount - I'd really enjoy that as a possibility in order to view existing code when referencing it, with dash-like visualization. Thanks for a great plugin btw! I also found sublime thanks to it!

[ozra]

@josephwecker - well put.

I find it hard to see Nim without it really. The hump and snake styles are definitely hacky since they're inception (duh), so when half the road is already paved, why not make the wheel rounder and let those who are not tied up in habitual snake/hump have a less bumpy ride. (oooh, so close to a style war now ;-)

The changes in the compiler are isolated and unobtrusive. No cost at all is inferred on those who do not use the delimiter, and will not ever notice a thing. So, everybody can use their preferred style, not imposing they're own preference on other's code - even when making modules!
Can't imagine a better language then that! It'll make a great selling point too ;)
And everyone lived happily ever after.

[josephwecker]

Of U+00B7 and U+2014 the first (middle-dot) is definitely better than the second (em-dash) which has significantly different syntactical meaning and is also a double-wide unicode character which complicates monospace editors etc. I'm surprised that you found so little support for the others though- usually you can configure the font to use a backup font for glyphs it does not have. In fact, I'm having a hard time finding monospace fonts that are missing any of them... Nevertheless, middle-dot is probably significantly generic.

BTW, by first suggesting the unicode version of the dash, @ozra I believe was purposefully avoiding a political battle. For the record though, scanning the current code base (minus external libraries of course), by far the most common usage of the minus operator where it would conflict with just using a normal dash as part of the identifier (ala CSS etc.) is variations of let last = c.code.len-1 Almost 100% of the minus operator without spaces around it are -1 or -2 suffixes.

[ozra]

I agree on the middle dot, and it was also the one suggested by @Araq. A very good suggestion imo, since, getting a bit philosophical:

[edit: be forewarned: this is a long philosophical rant. ..but with a happy ending.. eh.]

Using dashes to bind words are a trait of the writing rules of many modern germanic languages (in the norse languages like my Swedish, it's very common). That it has taken strong ground in the programming-, web- and file-naming-world ([sic] swedish writing rules purposefully used) is ofc. because of that and the simple fact that it's not a space. A space ofc would make much parsing hard, and intention communication more cumbersome. In written English on that note, words are always, with few exceptions, written apart. So, in a way the dot is the middle ground of written English and other germanic languages. Further evolving the delimiter from the dash stage. The humpStyle and snake_style goes without saying, they're not made to be the "scientifically and aesthetically most appropriate for readability", but rather are contrived "hacks" to manage with the characters allowed in early ASCII based syntax contexts.
If perhaps in some part of Asia a certain symbol is so extremely connected to word binding, and it sits well in the Latin script, there'd be room to add that too. Who knows, it might get such mind share that it revolutionizes written languages all over the world and we come to take that for granted. Just as many take braces and semi colons as a given programming syntax standard feature of the gods.

I don't deny anyone to use those contrived notations because their habited to them. We're all habitual. My preference is to expand and upgrade my habits constantly and consciously, to get what I want done, done with more flow.

I've seen studies supporting both hump and snake style as being the most fluently comprehensible one (not taking dashes into account here). Some involving coders (habituation already in place), non coders, aspiring coders etc. So the quality of currently available studies could be questioned.

So all in all, let's support all three, and with the middle-dot, we've reeeeally gone the middle road. In a good way. And once again, let programming teams themselves decide their preferred coding style conventions. In the Nim compiler source it's obviously hump, it's stated in the internals doc - and that's fine. That is what I will use there.

@josephwecker - interesting analysis of the source base. Further support that it wouldn't even make the existing code base confusing to read in such a style, and therefore definitely not code produced by someone versed in the style (that is - subtraction [and other operators] will always be spaced, by stylistic convention) (this was a concern raised on IRC btw).

[refi64]

Please, no. Imagine reading someone elses code and trying to figure out if you're reading unicode dashes or subtraction operations.