3 ms·

So that the compiler or interpreter knows the extent of the variable token. Without spaces allowed you would need some other way to tell it where they start and

So that the compiler or interpreter knows the extent of the variable token. Without spaces allowed you would need some other way to tell it where they start and end, like quotes or a special declaration, which would be harder for the brain to parse. If you know a better way please share it.

rileymat2 2y ago
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 2y ago
  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.
  - rileymat2 2y ago
    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 2y ago
    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 ;)
  - navane 2y ago
    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 ); }
- ReleaseCandidat 2y ago
  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 2y ago
> 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)`.

rileymat2 2y ago

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 2y ago
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.
- rileymat2 2y ago
  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 2y ago
  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 ;)
- navane 2y ago
  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 ); }
ReleaseCandidat 2y ago
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 2y ago

> 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)`.