4 ms·

In traditional programming languages the origin of such problems is the straightjacket of the ASCII character set. When a programming language is designed now,

In traditional programming languages the origin of such problems is the straightjacket of the ASCII character set. When a programming language is designed now, the right way is to use distinct Unicode characters wherever necessary, easily avoiding all ambiguities.

layer8 3y ago
I would like to agree, but since keyboards are still mostly ASCII (in particular with regard to punctuation characters), most people don’t have a Compose key configured, and also don’t want to be constrained to editors with an input method tailored to that programming language, it would be an uphill battle for adoption.
- keybored 3y ago
  Interestingly though even C had the “not on my keyboard” problem, hence the trigraphs. And still they ended up having to use “lexer hacks”. Modern languages could use a more legible (unlike C trigraphs) solution as write-only alternatives (a canonical formatter could normalize). Since modern language can now use the whole (woah) printable ASCII range. :)
  - layer8 3y ago
    The trigraphs feature was a committee invention for something that had already largely stopped being a problem at the time it was decided. Nobody really used them, other than by mistake, which is why they were now removed in C23 (and already earlier in C++). A write-only solution is virtually the same as an input method, or you have to support different representations in source code after all. It also doesn’t fix all syntax ambiguities. For example you may want to allow “<<“ as an ASCII version of “«”, but then you still have possible ambiguities with consecutive “<“s (does “<<< … >>>” mean “<« … »>” or “«< … >»”?). And it has the drawback that you have to learn how to type the symbols that look differently from their ASCII sequence counterpart in the canonical version.

4 ms·

In traditional programming languages the origin of such problems is the straightjacket of the ASCII character set. When a programming language is designed now,

by adrian_b 3y ago

layer8 3y ago
I would like to agree, but since keyboards are still mostly ASCII (in particular with regard to punctuation characters), most people don’t have a Compose key configured, and also don’t want to be constrained to editors with an input method tailored to that programming language, it would be an uphill battle for adoption.
- keybored 3y ago
  Interestingly though even C had the “not on my keyboard” problem, hence the trigraphs. And still they ended up having to use “lexer hacks”. Modern languages could use a more legible (unlike C trigraphs) solution as write-only alternatives (a canonical formatter could normalize). Since modern language can now use the whole (woah) printable ASCII range. :)
  - layer8 3y ago
    The trigraphs feature was a committee invention for something that had already largely stopped being a problem at the time it was decided. Nobody really used them, other than by mistake, which is why they were now removed in C23 (and already earlier in C++). A write-only solution is virtually the same as an input method, or you have to support different representations in source code after all. It also doesn’t fix all syntax ambiguities. For example you may want to allow “<<“ as an ASCII version of “«”, but then you still have possible ambiguities with consecutive “<“s (does “<<< … >>>” mean “<« … »>” or “«< … >»”?). And it has the drawback that you have to learn how to type the symbols that look differently from their ASCII sequence counterpart in the canonical version.