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.

[ozra]

That concern has been raised. And concluded a non issue. Even if it had been the minus sign used! But a symbol that clearly disambiguates them will be used. See @josephwecker analysis of the nim source, which is not even in dashish-style at https://github.com/Araq/Nim/issues/2811#issuecomment-105654613

To take the extreme example:

var some‑foo = the‑magoo - (mega‑number + a‑magic‑val - reduction‑sum) / the‑bunch

Also, if you have operators highlighted with another color, its laser sharp.

Which rune to use is still under consideration, leaning towards · (U+00B7). Suggestions? - Keeping in mind that it is what you may read, since you obviously will use another style, writing I'm guessing.

With this, it would look like:

var some·foo = the·magoo - (mega·number + a·magic·val - reduction·sum) / the·bunch

I think there still could be a better rune choice..

[def-]

@ozra And without spaces it becomes unreadable:

var some‑foo = the‑magoo-(mega‑number+a‑magic‑val-reduction‑sum) / the‑bunch

The only ones I'd be ok with are · and ␣ as alternatives for _, both of which are listed in the visible unicode substitutes for whitespace characters in https://en.wikipedia.org/wiki/Whitespace_character

I'm still not sure if this is actually a useful thing. Maybe you could set up your editor to display the underline differently in identifiers instead? Similar to this for haskell: https://github.com/enomsg/vim-haskellConcealPlus

[dom96]

To some people the middle dot will mean multiplication, as such I think using · is not a good idea.

[ozra]

That's a non-argument. It's exactly the point that has been brought up again and again. No-one writes code like that. Those who use dash-style certainly doesn't, and always use spaces - and the only chance you'll ever read dash-style code is if someone who codes that wrote it. Those who don't use the style almost always use spaced operators too. You might not want to mix 'strong spaces style' with regular dashes - but I wouldn't use that style anyway, even though it's a cool concept. Once again look at the conclusion on the nim source: almost only for foo in 0..a.len-1 constructs are written without spaces (which should be for foo in 0 ..< a.len me thinks). But once again, that's a non-issue, simply re-inforcing that you have no reason at all to worry about the world being taken over by dash-delimiters without spaces between operators.

Well, the ␣ is out of the question - it's as bad as underscores.

But yet one bump on 00B7 then.

@dom96 - I agree, that's the one concern I have with the B7-dot.

[refi64]

See, the thing is that it doesn't matter who writes code like what. This should not happen, and neither should this. But they happen. Because what you see is more relevant than what you know. This:

v = 1+2 * 3;

is a bug that has happened in programs before. Everyone knows that multiplication has higher precedence than addition. Everyone knows that you need braces around multi-line conditionals. But it happens anyway.

So, this is fine, but please anything except the dash and the middle dot. I agree with @def-; no matter what is considered good style and what makes sense, these errors will happen, and nothing should be added that makes them more annoying. Please.

[josephwecker]

I think consensus (for what it's worth) is leaning toward U-00b7. Summary of rationale stated plus a couple more:

• Broad support in common monospace typefaces
• Visually distinct from ascii dash-minus glyph
• Has a precedent in other languages (see http://golang.org/src/runtime/asm_386.s)
• Semantic precedent as a visual substitute for whitespace
• Can be input with keyboard somewhat easily on most OS'es (not a prerequisite, but nicer than some of the other codepoints)

In the bigger picture, just to reiterate- this feature would cause no harm to any existing preferences or existing code. The glyph can already be used in identifiers and operators - this is about some other piece of code being able to use camel-case or underscores to reference an identifier that was written with interpuncts.

[ozra]

This is redundant of me, but I have to quote this to emphasis it, because everyone and their mothers are screaming as if bomb planes are gonna come in and wipe their houses with glyphs - once again:

... The glyph can already be used in identifiers and operators - ...

Whether this is implemented or not - I can use any fucking unicode character in existance in identifiers in Nim right NOW. The change just makes sure that You don't have to use it even if I do. The alternative is, if I make a module using unicode-dash - or fucking monkeys - you have to use them too. See the upside now??

@josephwecker - nice summation. The alt-gr + . was a bonus! Thanks for that tip, if this becomes final glyph/rune. I'm a well bit into coding it now - since it's my first 'piler mod, I'd be happy to take this one and make a PR when it's done, if you don't mind? It would be fun to contribute (even though in this case it seems rather resisted..)

[ozra]

@kirbyfan64 - I have coded with dashes a few years now (the minus symbol shared as identifier part and subtraction symbol) and never - never - encountered a problem stemming from its use. That's got to count for something! Because I'm faaar from perfect! Brace-syntax mistakes, like the example you pointed to, is a whole different thing. There I have been burned at times. So, they can obviously not be compared. I find the pragma syntax in nim more confusing. So, ofc. your mileage might vary.

[josephwecker]

@ozra I haven't had a chance to even look at what I started yet, I just remember it mostly boiled down to a comparison function in compiler/ident(s?) or something and some tests. It's all yours :-)

[ozra]

Hacking happily away :)

[Araq]

@dom96 " middle dot will mean multiplication"

Well that's not what Nim's rules say: Any unicode letter outside the ascii range is an ordinary identifier, not an operator.

[dom96]

@Araq Indeed, I only just realised that. According to your philosophy we should accept this, so, go for it.

@ozra I understand that arguing with so many people can be frustrating and that you are passionate about this feature but I would appreciate it if you refrained from swearing during these debates.

[ozra]

@dom96 - yes, you're right - it would have been better to explain the true feature of it for a non-user of it to begin with, more concisely - I'm truly sorry for falling to strong words for no good reason - not very constructive.

[ozra]

Well, the code is ready now, and looks clean. There is one proc in the lexer that perhaps should be refactored to begin with, but since hash-code was repeated verbatim inline there, I took the easy path for now and just built upon it.

There is one problem to solve: which Unicode to give the magic property. The "middot" is more confusing then a dash - because dot-accessors are always written without spaces around them - and it becomes muddy when looking at the code. So it is probably not the optimal one.

~~Note that the nim syntax highlighter is buggy: it highlights len if there's a Unicode glyph immediately before it in an identifier. Please hint me as to where to report this bug, or where I can fix it The highlighter bug is more severe with proc identifiers, where any Unicode messes it up. It would be good to fix that before looking at examples to find the most suitable Unicode glyph.~~ - fixed it.

Example:

proc hash·ignore·style*(x: string): THash =
  var h: THash = 0
  var i = 0
  let x·len = x.len     # not that clear - is it? (also note the highlighter bug)
  while i < x·len:
    var c = x[i]
    if is·middot·rune(cstring(x), i):    # note the highlighter bug here also
      inc(i, 2)
  # ...

Compare dashes (just for comparison)

proc hash‒ignore‒style*(x: string): THash =
  var h: THash = 0
  var i = 0
  let x‒leng = x.len     # now it's more obvious (len_g_ to avoid the highlighter bug)
  while i < x‒leng:
    var c = x[i]
    if is‒middot‒rune(cstring(x), i):
      inc(i, 2)
  # ...

[josephwecker]

Github uses linguist - which in turn is using this commit of @Varriount's nim syntax def for sublime. You'll need to do a pull request to the latter and then a pull request to linguist asking it to look at the more recent commit.

(I suppose that fix applies [using unicode in identifiers] regardless of the status of this feature).

I was worried about middot mixed in with normal dots looking off... To be honest I personally do not mind after looking at it. It has a certain symmetry- like lower-dot is a dispatch whereas middot almost implies already-bound-and-evaluated... And, if it gets ugly, one can simply use the middot for stuff that they export for library compatibility, and internally use a unicode version of the hyphen or something as I originally intended ;-)

Syntax highlighting can also further differentiate the dot & middot if someone wants.

[ozra]

Yes, I think it's to hard to tell before highlighting looks as it should. Well, I gotta get some sleep. So will have to take a stab at that in a few hours.

[josephwecker]

Here's an example of how it looks w/ slightly more correct syntax highlighting.

Not bad, but, to be honest after stewing on it, I've changed my mind. I'd rather have hyphen and/or nonbreaking-hyphen (U+2010 & U+2011) be the ones that get fuzzy-matched. The minus operation comes up even far less than using the dot calling convention...

I could live with the middot and feel it was an improvement but would be far more excited about U+2011 and U+2010 hyphens. Again, this isn't an attempt to persuade anyone about the wisdom or lack of wisdom in using said hyphens since they can already be used- just that they should be 'soft' like underscores when they are used.

[Araq]

@ozra It's likely that I will accept such a PR, but I really consider fixing the damn font the superior solution:

• everybody knows how to type and read '_'.
• doesn't require a language change.
• it immediately fixes all code out there including C and Python code which_is_full_of_underscores.

[ozra]

Ok, I've fixed the syntax highlighting and made a PR. See if Varriount can do the magic to propagate it to githubs understanding.

@Araq well to me, unfortunately, it's an inferior and hacky solution.

• I for one will code with dash-like identifiers. So either no one will use my eventual modules (cause they hate dashes), or we can introduce a magic to cater to stubborn bastards like me (and I do think there will be more people enjoying the feature!).
• When it's time to diff with meld (or whatever..), view it on github, or make an edit in vim via ssh on a remote machine - the code will schizophrenically look all different. I want to see what I get.
• I'm OK with other people having their preferred code styles - it could be nice to have a 'dashier' presentation of such code, but it's not that important to me. It must first most be clear what's actually there. What I'll be working with day in and out is mostly my own code. Then I want it to be consistent and that what's seen is what's there.

@josephwecker - what about font support for those?

[josephwecker]

Typeface	U+2010	U+2011	U+2014
Consolas	:+1:	:x:	:+1:
Courier	:+1:	:+1:	:+1:
Courier New	:x:	:x:	:+1:
Fantasque	:+1:	:+1:	:+1:
Hermit	:+1:	:+1:	:+1:
Inconsolata	:x:	:x:	:x:
Liberation	:+1:	:+1:	:+1:
Libertine	:+1:	:+1:	:+1:
Menlo	:+1:	:+1:	:+1:
Meslo	:+1:	:+1:	:+1:
Monaco	:+1:	:+1:	:+1:
Osaka	:+1:	:+1:	:+1:
PT Mono	:x:	:+1:	:+1:
Ubuntu	:x:	:x:	:+1:

[ozra]

@josephwecker - I see two problems with the 2010-11, otherwise x2011 would be preferred I guess (nb):

• That they look just like we want ;-) (but are not subtract-sign) - highlight ofc. settles this
• More importantly: None of 'Ubuntu Mono', 'Source Code Pro' (and basically all fonts I tested that aren't "top names") supports them. The former is quite a widely used font.

For wide support it's basically x2014 from those reviewed that fit the bill. It also differ from minus more clearly.

[ozra]

WTF! Ubuntu mono does not work for me! - You're sure you don't have font-substitution for missing glyphs on or so?

[josephwecker]

That one I didn't have locally so I typed it in on their site. It may have been a glyph they added recently. In fact, my version of Inconsolata may be pretty old too. Most typefaces are constantly adding new unicode glyphs. I forgot about source code pro. Visually U+2011 looks better in most fonts, IMO.

Like I said earlier though, in most OS'es there are ways to indicate a "backup-font" when a glyph is missing (haven't looked it up in a long time but remember it exists)- so there are workarounds so you can use the "correct" one without infecting Nim with a decision that is only relevant due to the state of fonts in May of 2015 ;-)

EDIT: You were right- the browser was compensating for me- table edited to reflect absence. The rest may be outdated but are correct as of my currently installed versions :-)

[josephwecker]

Added U+2014 to the table as well. It's better supported but I must say I don't like it- it's a double-wide unicode glyph and semantically used for very different things than the hyphen.

It's supposed to be the equivalent of three dashes- not---as---readable---identifier

[refi64]

Why not the two- and three-em-dash? U+2E3A and U+2E3B, respectively. Look:

a⸺b-a-b

The dashes are more visually distinct.

[josephwecker]

@kirbyfan64 Alas, almost no font support. Also, I assume those are also meant to be quite wide (as wide as 2 or 3 'M's :-) Figure-dash would be a great width, but it also has almost no typefaces supporting it at this point.

[ozra]

@josephwecker - you're right on the infection part, and still, we're also producing code today, and it should be readable by others. On the other hand, while there already is a check for a unicode, and dash-like glyphs likely never will be seen as anything but delimiting chars, and never as operators (some other runes may be reserved for operators in the future) - it would not harm anyone, and rather be better, to capture a range of runes - say 2010 - 201* as magic unicode chars. It won't make compilation more complex nor slower, just an additional conditional. But, then, on the third hand (heh), it would be good to at least get some sense of standard on dash-usage for dash-fans, thereby not confusing the editing unnecessarily, even though they can be intermixed freely, a manager of a code base might want x2015, and then someone enters x2010's, veeery confusing pull request discussions around seemingly same chars - here the arguments about glyph likeness are valid!

The x2011 is kind of the best choice because of its non breaking semantics, also it is what "dashers" actually want. And the point of this whole exercise is to let anyone use what they want, and add transparency to cross-module use. Instead of anyone using what they want, and enforcing their choice on others. So going with the 'middle-road' options might be a worse idea, because then some of us end up using dashes anyway, but then they're not transparently accessible to the old-school hackish syntax fans. And one also have to resort to a half-assed rune when accessing old-school syntaxed libs anyway.

@kirbyfan64 - The first symbol there (u2e3a) is unfortunately just a square on my computer..

[josephwecker]

@ozra :+1: I agree. I actually think the range idea would work well if it was strictly limited to 'look-alike' non-operators (i.e., exclude official 'subtract' glyph), namely: 2010 - 2015. It has a precedent in languages that treat many of the unicode space characters as being equivalent to 0x32. It wouldn't need to be mentioned in the manual, and I think there would be little/no confusion specifically because they're magical. You could say "you can't use normal dash- use the unicode hyphen" and even if they picked the wrong one it would be "the same."

But I vote leaving that for the future and sticking to U+2011 for now for simplicity and to test the feature generally.

[ozra]

@josephwecker - yes, I like babbling around the possibilities, which often leads to excluding most options, haha. I also think the U2011 is the best route - even though my fave font misses it. I'll take one for the community ;) I will switch to it in my tests for now to see how it plays out.

[ozra]

I've been sitting and editing with middot (for reference) and nb-hyphen interchangingly. Then I tried U+2013. As you know, I'm looking for the "optimal coding experience". U+2013 ties the identifier together much better, while not being double width in non-mono fonts. It makes the identifier really pop out as a homogeneous word, increasing the read-flow considerably, while also separating it clearly from minus. It's not semantically correct by far, but I've tried it in many settings, mono, common sans serifs, etc. It's widely supported, and looks good in a multitude of settings, it will not be legible for use as an operator in the future (not a mathematical symbol), etc.

I actually think this is the best visual experience - not typographically or design-wise - but information-processing-wise. I am prepared to sacrifice the semantic value for that.

How do you perceive this one, @josephwecker, usable?

Just first cut-n-paste throw-up code I came across, with U+2013, highlighting is broken for this one too, and my fix for NimLime is not accepted yet. Still, even under these erroneous conditions, with idents split up in color, they still hold together well!: [edit: just nim'ish'ified the throw up src a bit for viewing purposes]

# Purelse pseudo mish-mash livescript, re-lexed to nim'ish for highlighting test
proc blargh‒pseudo‒limits:
    # ... snip ...
    functor.rank‒angle‒from = (buf) => functor.rank‒angle( buf[0] - buf[1] )
    functor.rank‒angle = (v) => v / current‒outer‒wall‒limit
    # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

    functor.do‒derivatives = (buf) =>
        if not buf || not buf.is‒buffer
            say‒alert "DerivativesMutator._() - arg isn't a buf!", buf
            exit 1

        tangent.acc slope = buf[0] - buf[1]
        say "tangent = ", buf[0], '-', buf[1], '=', tangent[0]

        h = highest tangent, normalization‒limits‒lookback‒length
        prev‒h := m‒max h, prev‒h * roof‒hold‒weight
        l = lowest tangent, normalization‒limits‒lookback‒length
        prev‒l := m‒min l, prev‒l * floor‒hold‒weight
        current‒outer‒wall‒limit := m‒max(prev‒h, m‒abs(prev‒l))
        say "tangent limits = ", h, prev‒h, l, prev‒l, current‒outer‒wall‒limit
        normalized‒tangent.acc slope / current‒outer‒wall‒limit
        say "normalized‒tangent", normalized‒tangent[0]

        rotation.acc (normalized‒tangent[0] - normalized‒tangent[1]) * 0.8
        functor

    # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
    if source‒model
        say "DerivativesMutator:: acc fn uses source‒model acc and then pull"
        functor._ = => # *TODO* actually, we should completely ignore what arguments may or may not be and simply pass on what is passed!
            acc‒result.apply source‒model, arguments
            functor.do‒derivatives source‒model
    else
        say‒alert "DerivativesMutator:: acc fn is stand alone - we work in the dark"
        functor._ = functor.do‒derivatives

    functor

[josephwecker]

:+1: Looks better than I would have thought and I'll definitely use it, and as far as semantics at least it's definitely not a potential operator. Let's put some miles on it and see if it begs to be changed in the future :-)

[josephwecker]

(P.S.- you can probably ask github's linguist to just point to your fork temporarily if you want- this is one of the few times where it probably really makes a difference to have github's syntax highlighting changed. You can reference this issue or PR in your description of the pull request to them.)

[refi64]

+1 for U+2013. Looks visually distinct also:

a‒b-c‒d

The a looks connected to the b.

[ozra]

Glad to see we're arriving at something more acceptable and enjoyable, and/or at least tolerable :-)

@josephwecker - linguist? Ok, I'll google hub and try it..

[ozra]

Haha, shamefully admit, I don't even have a clue how to go about it. Haven't used much github features... Just sleep on it and hope it's pulled tomorrow B-)

[josephwecker]

I tested your NimLime change in sublime (sorry, you don't have issues enabled for your fork so I'm going to write about it here)- it looks great except one of the source.nim support.function.any-method.nim isn't working - the one when it is followed by parentheses. If that bug gets hunted down (I tested in sublime 3- I guess there's a chance it's a bug in sublime), simply fork github/linguist, git rm the NimLime submodule, and git submodule add your NimLime in its place, commit, and send a pull-request upstream for the github devs to handle in the morning.

I was just going to do it but ran out of time. BTW, that dash is growing on me more and more.