So that the compiler or interpreter knows the extent of the variable token. With...

rileymat2 · on May 21, 2024

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 · on May 21, 2024

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 · on May 21, 2024

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 · on May 21, 2024

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 · on May 21, 2024

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 · on May 21, 2024

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

ReleaseCandidat · on May 21, 2024

> Without spaces allowed you would need some other way to tell it where they start and end

That's not a problem at all, as long a a newline isn't treated as space and you don't use ML style function application, where a space is used to separate the argument(s) from the function name - `f x` instead of `f(x)`.