On: CamelCase vs underscores: Scientific showdown (201...

[rileymat2]

I am not picturing why this is true, if you cannot use key words as parts of variables (alone separated by a space) and lines end with a newline or semicolon (some symbol)

The first restriction might make this a problem. I am not saying it is a good idea, but it is not obvious to me.

[delichon → rileymat2]

Removing keywords from variables is a big sacrifice when they are often such common glue words, like `and`, `or`, `if`, etc. Say `and` is the keyword and you want a variable called foo_and_bar. To get such words back you would need to add something so that the parser knows if

  foo and bar == true

means

  foo && bar == true

or

  foo_and_bar == true

?

You could fix it with ugliness like making the keyword `@and` or some such, or the variable `foo @and bar` but that's not an improvement.

[navane → delichon]

We are already not allowed to use keywords as variables, this wouldn't change that.

I've never written a compiler, but I don't see how the last lines are harder to parse:

  if ( thisLooksAppealing )
  {
      youLikeCamelCase = true;
      votePoll( camelCaseFormatting );
  }
  else if ( this_looks_appealing )
  {
      you_like_underscores = true;
      vote_poll( underscore_formatting );
  }
  else if ( this looks appealing )
  {
      you like spaces = true;
      vote poll ( space formatting );
  }

[rileymat2 → delichon]

Yes, it is, but it would also change the language, it is funny I forget c++ has “and” because && is so ubiquitous. Likely you will get changes so “if” is ? Or something. (Like we wee with ternary operator)

Like I said, I can’t picture the requirement, but am not sure it is a good idea.

[ReleaseCandidat → delichon]

That's not necessary at all, even FORTRAN managed to parse

   DO 10 I = 1.100

as

   DO10I = 1.1

and

   DO 10 I = 1,100

as the beginning of a loop ;)

[ReleaseCandidat → rileymat2]

You can parse the whole expression / statement and decide what it is.

You have to be careful with infix operators, but there is always Haskell's solution of adding backticks for infix names.

So add(a, b) is the same as a `add` b

But without joking, a _real_ solution to infix operator names would be a backslash as prefix, as pseudo-Latex-style, so a \add b