Variable name with any character and whitespace

[ghost]

These features kinda have something in common so I just put them in the same request:

Feature 1:

One feature I would like to see is the ability to use whatever character as name eg.

ƒ = (name) -> ...

ƒ "load models for view"

or

π = 3.14

This is already possible (also means that it's simple to do in JS) if you are doing like this:

o =
  "ƒ": (name) -> ...

o["ƒ"] "load models for view"

If this was a built in feature we wouldn't have to declare it as an object method and also don't have to call it with brackets.

Why should $ be allowed and not ß Ω £ π and others.

I can't think of any drawback with this feature since it's already possible, with more code. CS would just make this simpler so the code gets prettier.

Feature 2:

Another thing I would like to see is acceptance of whitespace in variable names eg:

`create a new app` = (app) -> ...

`create a new app` "test"

o =
  "create a new app": (app) ->

o.`create a new app` app

These are just suggestions borrowed from Ruby where it runs a shell command:

`echo hello`

Also Neo4j is using them to allow attributes with whitespace:

person.`first name`

Why I think it's a good suggestion.

I know it's an old habit to use camelCased variable names but I just don't know why we still have to do that. It collides with literate programming. Also being forced to hit SHIFT for each word just doesn't make sense, not to mention that this just makes the whole program much more fun to read. Just read it like you read a book. Why suddenly reading sentences in camelCase or preventing variable names to be too long (thus unreadable)?

I could only imagine that this would open a new door for literate programming style in CS. No need to declare a function and have a comment above it explaining what it does. The code itself should be the documentation.

And as mentioned you can already have whitespace but a lot of programmers don't want to do something like:

o["create a new app"] app

o["load view for page"] = (page) -> ...

why everyone still prefers camelCasing the name.

Javascript is very flexible under the hood but it's not smart enough to allow users to use the cool features with ease. "Smell but don't taste".

For me this is something CS could take care of very easily and would make everyone love to have descriptive names thus indirectly making the whole app more of a literate program, for free.

[showell]

See http://www.python.org/dev/peps/pep-3117/ for more inspiration.

[friggeri]

Using unicode characters as variables already works :

coffee> ƒ = ->
[Function]
coffee> π = 3.14
3.14

[ghost]

Damn what a miss. I must have tested it on the node REPL and thought it was coffee.

[showell]

I don't think spaces in variable names is gonna fly. The strong convention is to use underscores, like so: load_view_for_page.

[ghost]

How would the parser disambiguate between the minimally required significant whitespace, additional presentational whitespace, whitespace delimiters ([first variable name, second variable name] = array), function calls (func name a, b, c), and variable names containing whitespace?

[gkz]

If you read the initial post you will see that he proposes enclosing the names with some character, in his example the backtick:

`create a new app` = (app) -> ...

`create a new app` "test"

That character is currently used for embedding JavaScript however, and even if it was available it would be inconvenient to use. Thus, a different character or set of characters needs to be devised for this purpose.

+1 I support this if a good system can be devised, as it would be very useful for a project I am currently working on.

[ghost]

The example presented uses only the space character...what about tabs and newlines, which are also considered whitespace? How would they be interpreted for assignments and references?

[ghost]

@showell Nothing reads/writes better than whitespace. Using _ is just an ugly hack to make it more readable. It tells us that people really care about readability. Also I don't think it's healthy to keep doing things in a way just because it's a tradition. Indentation instead of curly braces is one good example of doing thing in another way to make it more readable, no pyramids with {}. Having whitespace in variable names could be another.

@kitcambridge Whatever character to deal with this the variable name would end with the closing character. It's just like how {} is used. You can have whatever white space you want since CS will just look where } is used to know that the object is terminated.

@gkz Yeah now I recall that that one is already being used. Perhaps ´something like this´. But I think others more experienced would make better suggestions than mine if they are decided to implement a such feature.

[x3ro]

Personally I think this would severely decrease code readability instead of increasing it, as you say. The reason why whitespaces aren't allowed in identifiers in most languages is because they create ambiguity, and that is exactly what would happen with such variable/function identifiers. Even if you surround them with " ` " or something else, so that the compiler knows how to parse it, I think that the programmer would have a much harder time reading the code. The reason for that is, imho, that you don't read code like you read prose. There's not much syntax in a book, for example, except for punctuation. Code on the other hand has lots of different syntax elements which have to be distinguished, and that is at lot easier, at least for me, when those syntax elements are tightly grouped together in neat little blocks, so that I don't have to "search" for the beginning or the end of an identifier. Therefore I give this proposal a definite -1!

[showell]

@johnnywengluu Just because some things that are done out of tradition aren't healthy doesn't make ALL things that are done out of tradition unhealthy. There have already been plenty of experiments with introducing spaces in places they don't belong, such as in filenames, and the pain points are extremely obvious. Your curly brace analogy is curious, because under your proposal, you would have to introduce delimiters where they were never required before. It seems like a big step backward to me.

If you're really passionate about this, I would just create your own fork of CS. Better yet, think about attacking this from a different angle. Your interest in literate programming is well-founded; perhaps an intermediate step would be to patch docco to clean up variable name presentation.

[ghost]

@x3ro I don't think that is a good argument. It's like the /reg exp code/. You don't actually "search" for the / in the code. A decent editor would highlight the whole chunk. Also it's like saying "I don't like string" since now I have to search for the start and end ". I can't get your argument since it's already in all programming languages. And I doubt any editor would ignore to highlight it since it would be a CS syntax. That would be kinda a bug in the editor.

Also I feel that these kind of arguments is like "no curly braces and post fix since I don't like it". It's good to have the (making sense) alternatives there since people are not the same and also situations may vary. Different styles for different needs. That is one of the reasons why I love CoffeeScript.

[ghost]

@showell I feel that it's more healthy to request for a feature than to fork, especially when you don't know whether it's a feature that is going to be implemented or not. I'll take a shot and see what people think about it. Remember, the thing is that JS is already allowing this, but you have to do it in the hard/ugly way. My proposal is to make it simpler to do it, nothing has really changed, but it makes a big difference when writing/reading.

Regarding your argument where I introduce delimiters where they haven't been required. It makes sense since you have to use delimiters for the compiler to get what is what. It's how Neo4j solved it.

person.`first name`

Also keep in mind, you don't have to use it at all if you prefer _ or camelCasing. Just like me avoiding using {} and using indentations instead. You will only be using delimiters when you want whitespace. Just like you want to surround an object property with " when you wanna use whitespace or whatever characters.

I don't want to base this discussion on args like "I had one less key roundtrip so this is better". But even if I did my counter arg would be that it's way better to hit ` than having to press SHIFT with your little finger in an inconvenient finger position for each underscore or capital letter. That already makes you type faster with ´.

Why not let the users decide what to use when, just like in Neo4j.

[ghost]

One more question that merits discussion: what would the compiled output look like? Replacing the spaces with underscores seems to be the easiest solution, though this would break parity with the original CoffeeScript source.

[michaelficarra]

This proposal (the spaces in identifiers) definitely will not fly with @jashkenas. Closing, but feel free to continue the discussion.

[x3ro]

@johnnywengluu Yeah, in such a short example you don't search for the "/". But I'm thinking of hundreds or thousands of lines of code with "whitespaced" identifiers all over. I just imagine it to be very tiresome to read, but you're welcome post a larger example that changes my mind :)

[x3ro]

@kitcambridge Would ´some variable name´ and some_variable_name result in the same variable being addressed if whitespaces are just replaced by underscores?

[ghost]

@x3ro I can't get why it would be tiresome to read. It would just be like strings with highlighting. People have big apps with strings all over. You don't have to search for anything since any sane editor will highlight strings and the same will go for variables. I don't get what "searching" you are referring to.

And let's face it, the reason why you aren't using camelCase but _ is to simulate white space. So why simulate it when you could actually use whitespace?

@michaelficarra Closing this ticket with argument "it will not fly with @jashkenas" is leaving me with a question mark. For a such potential feature (that also kinda is built in into JS) I feel it's closed way too early without serious consideration.

[ghost]

@kitcambridge I was thinking about declaring variables as object["variable name"]. The only downside seems to be that you can't know what the global object is for the current environment ("window" in browser and "exports" in node.js). So perhaps you want to just replace whitespace with _ or combine these two methods.

[michaelficarra]

@johnnywengluu: Okay, I'll re-open it and we can see what Jeremy has to say.

[ghost]

@michaelficarra Thanks. That's more fair, even if he will close it later on. But I hope it will be discussed with an open mind without arguments like it's not a convention or it will make it unreadable. That's very up to the reader just like postfix, indentations, ? operator, ->, no return, no (), and operator, everything is an expression, unless etc is giving you a choice. Those aren't questioned (now) why I can't buy these kind of arguments.

[michaelficarra]

Here's my argument against allowing this feature. Like @showell suggested way above, instead of delimiters on the ends and whitespace in the identifier, just use underscores where you would want to put whitespace. What does the literal whitespace gain you that the underscores wouldn't? I can only think of one case: you're trying to make identifiers that look like _ __ _ ___ __ (a series of underscores separated by whitespace). And I don't think that's a legitimate scenario.

@kitcambridge: @x3ro: @johnnywengluu: they could coexist by using unicode escape sequences. See #1452 for a related use.

[ghost]

@michaelficarra For the same reason you would want to use it in object properties. You aren't forced to, but the feature is already there, for a reason. One gain would be that I just type as I always type when having multiple words. Another gain would be that I just read it as I always read when there are multiple words. Also currently I can't start a variable name with a letter or have some other non supported characters if I don't use [""]. See, JS is already giving us that ability to use whatever we wan't as name. There is no mismatch and this is not a new feature at all. It's about making things easier.

Let's think about the why nots. Why not use white space instead of a _ hack. I mean yeah, that has been how it has always been done, but technologies are moving forward. Why not just allow white space. What's really the big deal? Why make so much resistance for a such reasonable thing? And to be honest, I think this has become more of a religion thing or following the crowd, why I hope hearing more solid args.

I put functions in an object and then call them with function _ just to have it more readable:

_ "add view once",
  "view to add": _("category detail view", config)
  "view to add to": @get("view")

That is a hack but frankly it has made my app much more readable and enjoyable to code. Not just because of the whitespace, but that suddenly when the power to do so is there you wanna name/documentate stuff better. You start to get the philosophy behind literate programming. One thing always leads to another, and I feel this is a feature heading in the correct direction and will open many new doors.

´add view once´
  "view to add": ´category detail view´(config)
  "view to add to": @get("view")

Would be simpler than taking the function name as an argument to allow whitespace. No need to set up a "bootstrap" function, no need to declare functions in an object and more prettier code.

Here is another example of the current situation.

{"view added": viewAdded, "view added to": viewAddedTo} = doSomeRendering()

Here it returns a hash with readable keys. But when I assign the values to variables I have to switch back to camelCase or underscore mode. It's not pretty. Something like this would just fit better.

{"view added": ´view added´, "view added to": ´view added to´} = ´do some rendering´()

And since they are the same words we could do like this:

{´view added´, ´view added to´} = ´do some rendering´()

We could also allow assignments to skip ´ like this:

do some rendering = ...    

It's just making CS more awesome.

And keep in mind, yet again, it's already there in JS. I propose that CS, once again, fixes yet another thing JS should have been doing if they thought about the users. { "They have it like this": "for a reason" }. But then they say to the users: "yes we allow it, but you have to type much more, hah!" Now, that's a WTF.

Can't get why having this as an alternative is such a big no. CS is already giving people choice, it's in it's core philosophy, and this choice would only help if people choose to use whitespace. And for people who don't want that, don't use it, that's that, like with other parts in CS. But those who prefers this would be very thankful that the option is there. Also it doesn't mean that the people that think it's a bad idea will always think it's a bad idea. Heck, I thought to indent a whole app was a bad idea when I read a lot of posts against it in blogs and forums (it will break things easily, accidental tabbing, makes code messy...you all know how it goes). But it turned out to be one of the features I really love. If I prefer using {} tomorrow? Then I use {} tomorrow. Same thing with postfix vs blocks. Not a big deal in CS since smart decisions were made: Let the user choose what he/she prefers.

We could have an endless discussion in here or we could let the user, the one sitting in front of his/her app, choose. Let that user decide for him-/herself what is more readable, writable and enjoyable.

[jashkenas]

If you'd like to read more background on this, look at all of the conversations that we had while we were agonizing over standardizing on camelCase.

Personally, I'd love it if JavaScript style preferred dashed, Lisp-like identifiers: add-view-once.

But, unfortunately, JavaScript identifiers are camel case, and therefore CoffeeScript identifiers must be camel case. It's very important that CoffeeScript is seamlessly interoperable with JavaScript. If you're calling a library written in CoffeeScript from JavaScript, you shouldn't have["to call it like this"]()

[ghost]

@Jashkenas I've read the issue about why you chose camelCase. Then what about compiling the variable names to camelCase?

Declaration in CoffeeScript:

my company cars = [...]
create financial report = (transactions) -> ...

So if you are using CoffeeScript you can just call them with:

console.log ´my company cars´
´create financial report´ transactions

Which means calling it in JavaScript (you could also call them like this in CS if you prefer!):

console.log(myCompanyCars);
createFinancialReport(transactions);

We would use only valid characters in the variable names so it will be callable from JavaScript eg. can't start with a number or have unsupported characters in it. Just following JavaScript naming convention. That would solve the compatibility issue you were referring to and make it convenient for JavaScripters to use a CoffeeScript library while CoffeeScripters would have the bonus of using white space.

Win win?

[jashkenas]

Then you're creating a readability problem, where it looks like you're writing one thing, and you're actually writing another. Symbols and punctuation become an issue, as do multiple different strings evaluating to the same identifier. Finally, having to quote your identifiers is an unacceptable burden.

`writing a`.`value access`.`in an object`.`like this`.`is quite ugly`

[ghost]

There wouldn't be readability problem since it's highlighted just like a string. You wouldn't mix it up with anything. It's just adding the capability of white space through ´ delimiters. Aren't you over reacting?

I would prefer:

`writing a`.`value access`.`in an object`.`like this`.`is quite ugly`

over:

writingA.ValueAccess.InAnObject.likeThis.isQuiteUgly

You are used to camelCasing (we all are) why it first looks weird when we switch context. But seriously, which one is really the weird one here? You know it, you just have to admit it! It's just about habit and that was a pure subjective statement that shouldn't be used as an against argument. Your library compatibility was a valid arg, this one not so much to me.

With whitespace I could just read it which forces people to think about the documentation part taught in Literate programming. Jumping into a new code done by someone else would be more speedy if the developer understood to read the code is far more important than to type it fast. And the thing is that it gets faster to type with white space already when you are using more than 3 words in camelCased sentence and 2 words if the editor supports auto pairing (which is quite usual these days). Imagine more descriptive variable names.

Readability is an issue today, why people love Ruby, Rspec, Cucumber and all other tools to enhance it. Even Docco is loved since it's focusing in understanding a code. But it's much better if the readability enhancements are taking care of by the language itself than a documentation generator creating doc based on comments.

Also, your example is kinda zooming in into one piece of a whole system and doom the entire thing to fail. That's what biased JavaScripters are doing all the time in JS vs CS. They use the most extreme edge cases and then say "Look, so ugly and unreadable". That's unfair. Yet again, let the users decide what to use.

There are a lot of examples where you would gain so much from it. Just having variable in local scope is one of them. You wouldn't even need ´ for assignment (if I'm not mistaking).

The more descriptive the name becomes the more you gain in speed in writing and reading it:

basic form for administration users = ...
console.log ´basic form for administration users´

Instead of:

basicFormForAdministrationUsers = ...
console.log basicFormForAdministrationUsers

Just compare them! I can't read the latter without really focusing on analyzing it. It takes so much more processing power in our mind to read it compared to the first one. So it's funny that readability args are used against it.

Not to mention if that is not your cup of coffee, you could just use camelCasing instead, even in CoffeeScript. Having ´ is just a way to tell CoffeeScript to create camelCased name out of it.

That means another big advantage too: You can call JavaScript variables and functions with:

´has empty states´
´last index of´
´sorted index´

Since they are just converted to camelCase. 100% compatible with JS and the camelCase convention. It would be something loved by many and I think yet another feature that will convert many JavaScripters to CS land!

[friggeri]

Another argument against your proposal is that it totally breaks any kind of code completion in most editors. Completing myLongVariable is easy, my long variable not so much (it would involve a lot of look backs).

[ghost]

@afriggeri You are looking from the wrong perspective. It isn't widely supported since it's not widely used. Imagine this was the case in the first place, then every editor would support it. Someone has to be first. Cloud9ide is a good editor I doubt they wouldn't introduce it if CS had support for it. People want their users happy and wouldn't say "Yeah I know it's supported in CS, but I want to make it difficult to users thus making less money!". That won't be the case. Like writing a new lang in the first place. "No one will use it since there is no support". We know better, support will come, period.

And to form a language on editors is foreign concept to me. Indentation anyone? I still have to analyze much more to just know in which indentation level I'm at. But I proposed a feature in C9/Ace and they loved the idea and said it would be good for Python indentation as well. Look forward instead of being limited by the past.

Browser breaks debugging totally. I can't see anyone here complain as much. CoffeeScripters are defending it with args like, support will come, just a matter of time now when CS is growing. Your args are really the ones JavaScripters use in JS vs CS debates. I don't find them attacking the real deal here.

Also, if it doesn't fit you (atm) then just use camelCase. But no one will ever support it if there was nothing to support.

I would appreciate against args that are more valid so we won't recreate a typical JS vs CS debate (http://net.tutsplus.com/articles/interviews/should-you-learn-coffeescript/), there is no point. The only valid arg (since it's attacking a real issue) imo was the one by @jashkenas about it would make JavaScripters not wanting to use CoffeeScript libraries, thus a risk that no one would wanna write a CoffeeScript library/framework with whitespace since that wouldn't gain as much popularity as the JS ones. But that seems to be solved now, even better than I imagined since you can call JS methods with whitespace too. Also now the ability to compile it down to underscore variables like:

current_active_states
create_user user

Or whatever pattern you prefer. It's powerful. There is so much to gain from this!

People think adding an extra compilation step is unnecessary. Let them understand the huge flexibility from it and how much time it could save.

In CoffeeScript you can now choose:

• to define objects with {} or omit them in some cases.
• to use postfix or block for if statements
• to use indentation or {}
• to use () for method calls with args or omit them

This proposal is following this philosophy, choice, let the user picks what he wants when he wants it. You can use whitespace/camelCase where it fits you. The proposal doesn't take value away, it adds value. Ask yourself, would this really be a feature people spit at? I doubt it. It would make CS more attractive and add productivity and joy in coding.

And remember, remember, remember, if you don't want it, don't use it. Now, no more such against args. Attack it with valid args so we all can figure out the real issues (if there are some left)!

[friggeri]

What I meant is that in order to complete myLongVariableNa in myLongVariableName, you just need to have a dictionary of all tokens present in your source. If you want to complete on my long variable na, you need to embed a parser in your editor to know what sequence of tokens is a variable. eg. if you have :

my name = ..
number  = ...

Knowing that my n should only complete to my name and not my number requires knowledge of the langage.

[ghost]

Yeah sorry for misunderstanding you.

But doesn't all smart auto completion functionalities require knowledge of a language? Even so, I don't think we should base language features on IDE features. Let them take care of those.

[friggeri]

I didn't say IDE but text editor, for a good reason. Anyway, I was just raising another argument against your idea. Another one is that on some keyboards, backtick is a compose key, which requires an extra key stroke in order to avoid having an accented character. Anyway, the idea could be interesting but I guess I disagree.

And about "more choices" is better, let's just add gotos to CS…

[ghost]

If backtick is a problem then we could find another character. I'm sure that wouldn't be that huge of an issue.

So you give me an editor arg. Then you give me a keyboard arg. Based on these we would have ditched a lot of syntax in langs. Perhaps camelCase would have been ditched since we are actually pressing SHIFT+key for the capital letter in each word. I can't see anyone suddenly raising complaints.

It just seems to me that these args you are raising is based on that it's not your style to use white space (yet?). No matter what I say you will just find something to kill it. Just like indentation vs curly braces. Or even CS vs JS. I don't want a such debate. That gets us nowhere.

CS let the user choose in a lot of places. This is one of the args people use against the JScripters when someone says something is not their style. Of course the choices have to make sense. But editor and keyboard args wasn't enough so now you give me a "goto" arg when I said let the user choose! A goto arg!!! Seriously, is this suggestion like adding a goto statement in CS in your opinion, only destructive behavior, nothing constructive?

There was a reason why I said valid args. CS should enhance JS. This enhances JS, not creating something new, but a different way to write/read it, just like you could omit {}.

Again, if you don't like this style, don't use it. Just don't prevent other people from using it. Being where CS is, it should know better.

[ghost]

I still maintain that the most significant weakness of this proposal is the necessary inconsistency between the CoffeeScript source and the compiled JavaScript—you can write my long variable name in CoffeeScript, but can only address it as myLongVariableName (or my_long_variable_name, my$long$variable$name, or whichever delimiter is ultimately chosen) from JavaScript. And it's unreasonable to assume that all developers who use CS libraries will want to write their own code in CS, so parity with JS is vital.

[ghost]

@kitcambridge It doesn't make sense to put $ between the words so I guess CS won't, ever, support that. They would just use camelCase or underscore (if the support is there and the author chooses that style).

I don't see an issue here.

[ghost]

@johnnywengluu Let's say that I'd like to use a CoffeeScript library in my application, but want to write my app code in JavaScript. I can use the coffee command to compile the library, include it in my app, and then access it from my JavaScript code.

But what if the library defines a method called my long method? I could reference it as my long method if I were writing my app code in CoffeeScript; however, since I'm writing my code in JavaScript, I must use myLongMethod. This effectively exposes different APIs to the two languages, and violates CoffeeScript's "golden rule" that "it's just JavaScript."

[michaelficarra]

@kitcambridge: you must have missed my comment above. Unicode escapes can be used to support variables of any sort, but @jashkenas turned that down in #1452 as unacceptable, even though you're making the choice to require that your users use unicode escapes if they're writing JS.

[ghost]

If you are writing JS you have to use their syntax, eg.

function(arg) {...}

If you are writing CS you cannot use that syntax but:

(arg) -> ...

So if you are in JS:

aVariableIDefined = ...

in CS

a variable I defined = ...

But it gets even better, you could just use it as it is in CS:

console.log aVariableIDefined

Since "a variable I defined" is just another way to write "aVariableIDefined" just like you don't want to write the verbose "for" loop in JS. Think of it as an alias.

I think you have misunderstood CS's golden rule. It compiles down to valid JS! Not that you must be able to use JS syntax in a CS file. They don't even want you to why they say don't use ` to write JS code.

[ghost]

@michaelficarra I did, indeed, miss your earlier comment. Thanks for the link. The trick would be finding a character that works...JavaScript's list of whitespace characters is quite extensive.

@johnnywengluu Huh? I said nothing about using JavaScript syntax in a CoffeeScript file. My point was that you're no longer exposing equivalent APIs for the two languages...I can use variable names containing whitespace in CoffeeScript, but have to remember that they compile into camelCased names when working with JavaScript.

To quote from the CoffeeScript web site (emphasis added):

The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly from CoffeeScript (and vice-versa).

I think that exposing one library API (that potentially includes identifier names containing spaces) to other CoffeeScript source files and a different one (where such identifiers compile into their camelCased equivalents) to JavaScript source files is far from seamless.

[ghost]

@kitcambridge Just that it will be the same camelCase API though. It's just a way to write a camelCased variable. This is to support the convention for all JS people without affecting the ones who love whitespace in sentences. You can use camelCased variable in your CoffeeScript files. But when you prefer whitespace, just go for the "white space" mode. It shouldn't be seen in a different way than this. It's already like this with {}, for and other constructs. They are a more convenient way to write the equivalent JS code, nothing more.

[ghost]

Here is a good example of how Neo4j is doing it:

START This isn't a common identifier=node(1) RETURN This isn't a common identifier.<<!!__??>>

http://docs.neo4j.org/chunked/1.6.M03/query-return.html

It's so amazing that they allow people to use whatever characters. It makes a huge difference.

Please reconsider.