3 ms·

The actual place where CFGs fail tend to be if types and expressions aren't parsed the same. This especially causes problems if your language's generics use `<>

by o11c 3y ago

The actual place where CFGs fail tend to be if types and expressions aren't parsed the same. This especially causes problems if your language's generics use `<>`, but even C has the `T * v` problem.

adrian_b 3y ago
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.

by o11c 3y ago

The actual place where CFGs fail tend to be if types and expressions aren't parsed the same. This especially causes problems if your language's generics use `<>`, but even C has the `T * v` problem.

adrian_b 3y ago

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.