Separators inside a var name

[Sebastian "lunar" Wiesner]

 Rainy <andrei.avk at gmail.com> at Montag 09 Juni 2008 19:29:

> I have a stylistic question. In most languages words in var. name are
> separated by underscores or cap letters, resulting in var names like
> var_name, VarName and varName. I don't like that very much because all
> 3 ways of naming look bad and/or hard to type.

Then you better get used to such names, as they are common for many widely
spread languages including C, C++, C#, Java, Python, Ruby, Perl and many
more ;)  You may like these or dislike these names, but you won't come
around them ;)

> From what I understand, scheme can have variables like var-name. I'm
> curious about reasons that python chose to disallow this.

"-" is an operator in Python.  How should the parser know,
whether "var-name" means "the object bound to var_dash_name" or "subtract
the object bound to name from the object bound to var"?

Scheme can allows such names, because its a functional programming language. 
Subtracting in this language is not done through operators, but through
functions.  Therefore there is a clear difference between referencing a
name or subtracting two ones: var-name vs (- var name).

> Another question I have is what other languages allow this naming scheme?

Other lisp dialects do, due to the same reasons as scheme.  

> Were there any languages that allowed space as a separator?

None that I know of.  Probably one could use unicode characters, that look
like a space in languages, which allow unicode characters in identifiers
(as Java or C#, iirc), but I doubt this.  Anyway, even if allowed, this
would be silly, since it obscures code to the eyes of the reader.

> What would be a practical way to separate variables from keywords in that
> case? "some long variable name", 'just a string', or maybe using 2 spaces:
> one var  +  other var  +  third var ? 

I can't image a practical way to allow a space as character in names, while
still maintaining it syntactic element for separation of names.  Quotes are
normally used for string or characters literals and a double space is hard
to distinguish from a single space, and things like ${a name with spaces}
is a lot nastier than names with underscores (which aren't bad at all,
imho).

> I think being able to easy have very long names for vars that are easy to
> type would be a fairly significant advantage.

Names shouldn't be long, they should be expressive.  If you can't give an
object a _short_, but _expressive_ name, your object is too complicated ;)

Btw, I don't really understand your refusal of underscores.  In my opinion
such names are harder to read than underscores, which look more like a real
space, because the leave a space in the middle of a line, that you look at. 
If they are too hard for you to type, whats the point in swapping the dash
and the underscore in your keyboard layout?

-- 
Freedom is always the freedom of dissenters.
                                      (Rosa Luxemburg)