4 ms·

C itself is not that hard to parse. The "lexer hack" thing is a theoretical impurity but it just means you have to add types to a type table -- and probably ope

C itself is not that hard to parse. The "lexer hack" thing is a theoretical impurity but it just means you have to add types to a type table -- and probably open and close scopes -- while parsing. The preprocessor though seems to be pretty annoying. C++ must be comparatively a lot harder to parse -- C++ syntax is a huge amount of complexity added to a system that wasn't designed with that in mind. That you link "Dangling else" is curious. The wikipedia page talks about "ambiguity" but in my mind it's no different than the ambiguity in "a + b * c", does it mean "(a + b) * c" or "a + (b * c)"? Well, make a choice and write it down.

skitter 2y ago
> Well, make a choice and write it down. Or don't and don't allow unnecessary ambiguity. For * and +, there's a agreed upon order of operations far more universal than a programming language, but it's sensible to use a partial order so nobody is mistaken about whether e.g. logical or and bitshift binds tighter. Similary C counld have just not have allowed omitting the braces around single-line else clauses and would have been a simpler language for it.
- ajross 2y ago
  > For * and +, there's a agreed upon order of operations So... we collectively made a choice and wrote it down, then? I think you whooshed on the point. The if/else ambiguity is just a precedence rule, like many others in the expression grammar of every (well, every non-lisp) language that exists.
  - kibwen 2y ago
    Needing to specify associativity for operations that have absolutely no reason to be ambiguous in the first place is a flaw of language design. It's needless complexity. Isn't C supposed to be a "simple" language?
    - ajross 2y ago
      You lost me. How does if/else have "no reason to be ambiguous in the first place". It's ambiguous in the actual language from which it was derived. English itself has no syntax for expressing a nested "if" such that you can match the right "else".
kibwen 2y ago
> it just means you have to add types to a type table -- and probably open and close scopes -- while parsing Which is a flaw that other languages don't have to deal with, because they learned from C's mistakes. There's no justifiable reason for a language's grammar to make this sort of thing necessary. C would be better--and simpler--without it.
- jstimpfle 2y ago
  Did they learn? What about Java or C# then, for example? I would like to have a better syntax too but it's a tradeoff. I really want to like more algebraic syntaxes like Zig/Odin/Jai but C's terseness and ease of use for the common, simple cases is unmatched unfortunately.

skitter 2y ago

> Well, make a choice and write it down. Or don't and don't allow unnecessary ambiguity. For * and +, there's a agreed upon order of operations far more universal than a programming language, but it's sensible to use a partial order so nobody is mistaken about whether e.g. logical or and bitshift binds tighter. Similary C counld have just not have allowed omitting the braces around single-line else clauses and would have been a simpler language for it.

ajross 2y ago
> For * and +, there's a agreed upon order of operations So... we collectively made a choice and wrote it down, then? I think you whooshed on the point. The if/else ambiguity is just a precedence rule, like many others in the expression grammar of every (well, every non-lisp) language that exists.
- kibwen 2y ago
  Needing to specify associativity for operations that have absolutely no reason to be ambiguous in the first place is a flaw of language design. It's needless complexity. Isn't C supposed to be a "simple" language?
  - ajross 2y ago
    You lost me. How does if/else have "no reason to be ambiguous in the first place". It's ambiguous in the actual language from which it was derived. English itself has no syntax for expressing a nested "if" such that you can match the right "else".

kibwen 2y ago

> it just means you have to add types to a type table -- and probably open and close scopes -- while parsing Which is a flaw that other languages don't have to deal with, because they learned from C's mistakes. There's no justifiable reason for a language's grammar to make this sort of thing necessary. C would be better--and simpler--without it.

jstimpfle 2y ago
Did they learn? What about Java or C# then, for example? I would like to have a better syntax too but it's a tradeoff. I really want to like more algebraic syntaxes like Zig/Odin/Jai but C's terseness and ease of use for the common, simple cases is unmatched unfortunately.