4 ms·
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 (s
by 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 agoRemoving 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 agoYes, 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 agoThat'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 agoWe 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 agoYou 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