Idea: add support for dashes in variable names, mangle them

[paulmillr]

Why dashes?

1. More readable than underscores.
2. JS has its own variable naming style (camelCase), which obviously sucks in readability.
3. Vars with dashes are invalid in js, so if we'll compile it with mangling, it won't violate js naming style.

Cons:

1. It would add more complexity
2. - will be prohibited from using as OP without indenation like a - b (which is good IMO).

Examples

add-user = (name, age) -> ...
remove-users-with-age = (age) ->
  remove-user user for user in users when user.age is age
add-users = (users) ->
  add-user user for user in users
class Thread-post

addUser ...
removeUsersWithAge ...
addUsers ...
ThreadPost ...

Examples

Clojure. Pretty readable.

reposted from jashkenas/coffeescript#2345

[gkz]

Still thinking about this.
I'm thinking if we did do it then I would compile add-user to add_user, and have - be aliases to underscores in the program. This way any compiled JS would still be easily accessible.

[michaelficarra]

So then add-user and add_user would be identical references? That may be confusing.

[gkz]

Yeah that's why I'm not sure about the idea. Any ideas on how better to do it?

[michaelficarra]

Use gensym, forget about preserving identifiers in the target.

[paulmillr]

I don't think there will be great impact of this it will be implemented as a simple converter to _. The main feature is that it allow to reuse existing javascript code, which is, in 90-95% of cases written in camelCase. Consider:

user = document.query-selector('.user')
user.add-event-listener 'click', ((event) -> console.log event), yes

id = window.set-interval ->
  console.log 'hello'
, 1000
window.set-timeout (-> window.clear-timeout id), 1500

encoded = encode-URI-component string
number = parse-int '5'
string = number.to-string!

page-text = document.query-selector('body').inner-text
logged-in = $('body').has-class 'logged-in'
obj = {a: 1, b: 2}
descriptors = Object.get-own-property-names(obj).map((name) -> Object.get-property-descriptor obj, name)

vs

user = document.querySelector('.user')
user.addEventListener 'click', ((event) -> console.log event), yes
id = window.setInterval ->
  console.log 'hello'
, 1000
window.setTimeout (-> window.clearTimeout id), 1500
encoded = encodeURIComponent string
number = parseInt '5'
string = number.toString!
pageText = document.querySelector('body').innerText
loggedIn = $('body').hasClass 'logged-in'
descriptors = Object.getOwnPropertyNames(obj).map((name) -> Object.getPropertyDescriptor obj, name)

[satyr]

encoded = encode-URI-component string

Wouldn't that be encode-uRI-component?

[paulmillr]

@satyr uppercase letters in vars with dashes can transform as-is, so no.

[satyr]

Uh right. It'd be author's choice.

• encode-URI
• encodeUR-i
• encode-U-r-I

would all work as encodeURI.

[paulmillr]

Yep, you've got it right.

[michaelficarra]

@paulmillr: doesn't that strike you as insanely confusing?

[paulmillr]

@michaelficarra no, it's one simple rule: a letter after - is always uppercased.

[michaelficarra]

Sure, the rule is simple, but it could lead to some really confusing errors when you're not thinking carefully about it, no?

[paulmillr]

Errors like what?

[michaelficarra]

Believing you're working with two distinct variables, when you're actually referencing the same one. It's easy to see, but only if you're actually thinking about the variable name transformation. Also, "How did I separate it above? Was it encode-URI or encode-U-R-I?". Maybe it won't be a problem for anyone, I'm just thinking of possibilities.

[paulmillr]

I agree this can cause them but I don't think it will be really popular error. This definitely deserves prototyping. I'll see what I can do.

How did I separate it above

And this type of confusion could only happen in acronym vars.

[goatslacker]

+1 for this feature.

I've implemented it in my toy language and while I've ran into the encode-URI issue already I feel the benefits far outweigh the headaches.

The dash isn't what's confusing, the DOM is confusing with their sometimes inconsistently cased acronyms.

[gkz]

I don't care enough about this feature to do it myself, but I will accept pull requests.

[adrusi]

I'd just like to say that I love this feature, but I totally disagree with "while I've ran into the encode-URI issue already I feel the benefits far outweigh the headaches."

while this is an awesome feature, the headaches caused by it could be almost impossible to track down. Suppose you have a metric called "TCHA" in your code (doesn't matter what it means) and you're using CAPTCHAs somewhere. Maybe you have two global functions called calc-CAP-TCHA which calculates the max TCHA possible at a given time and a function calc-CAPTCHA which generates a CAPTCHA image. I mean, this is obviously very contrived, and still the result of poor naming convention, but you never know when someone might run into something like this in real use.

This should at least be documented on the homepage so that users can find out about the feature without digging through the issue list.

[goatslacker]

It wouldn't be difficult to keep track of identifiers somewhere and throw a compile error when two identifiers mangle into the same camel-cased identifier.

I can provide a patch for this if there's interest.

[michaelficarra]

@goatslacker: I think that's a great solution.

[goatslacker]

Landed in 3b1a69d now you can call your function calc-max-TCHA instead since calc-CAP-TCHA won't compile :)

[paulmillr]

Why this was landed? I don't think stuff like XMLHTTPRequest is readable. But XML-HTTP-Request is. This ultimately solved a problem with acronyms.

edit oh well, I understood now what this did.

[michaelficarra]

@paulmillr is drunk githubbing.

[paulmillr]

[adrusi]

I might submit a patch to make it only fail on compile if it finds two variables which would mangle to the same thing but use different hyphenation. probably has to wait til tomorrow though.

[adrusi]

lol nevermind, i just looked at the commit info, seems that what you did.

so XML-HTTP-request would work, but would break if later you also used XM-LHTT-p-request? I see no more problems if that is the case.