I'll just drop this here for those looking to get started on interpreters:
And perhaps this for those leaning towards C:
Crafting Interpreters
51–60 of 62 posts
Re: Crafting Interpreters
#52Really I would love to know how parse context sensitive stuff like typedef which will have "switched" syntax for some tokens. Would like to know things like "hoisting" in C++, where you can you the class and struct after the code inside the function too, but I just find it hard to describe them in rigorous formal language and grammar. Hacky solution for PEG such as adding a context stack requires careful management o…
Another possible solution is the usage of functional parsers (e.g.: [0]) and making use of some form of the ‘do’ notation. Each step makes its result available to all subsequent parsers.
Re: Crafting Interpreters
#53I have bought the print version of this 3 seperate times to give as a gift, its excellent.
Thank you for buying copies! :D
Re: Crafting Interpreters
#54Really I would love to know how parse context sensitive stuff like typedef which will have "switched" syntax for some tokens. Would like to know things like "hoisting" in C++, where you can you the class and struct after the code inside the function too, but I just find it hard to describe them in rigorous formal language and grammar. Hacky solution for PEG such as adding a context stack requires careful management o…
C/C++ has one of the worst-designed syntaxes, its such a shame that entire families of the most popular languages ended up copying the same mistakes. I know it's no solace to you, but Rust and Go don't even have this problem Afaik, and it's avoidable by careful consideration.
I don't really know what you mean by "worst-designed syntax". Do you mean that the design process was bad, or that the result is bad?
Re: Crafting Interpreters
#55Re: Crafting Interpreters
#56Earlier quoted context omitted.
C/C++ has one of the worst-designed syntaxes, its such a shame that entire families of the most popular languages ended up copying the same mistakes. I know it's no solace to you, but Rust and Go don't even have this problem Afaik, and it's avoidable by careful consideration.
I don't really know what you mean by "worst-designed syntax". Do you mean that the design process was bad, or that the result is bad?
I meant exactly what the parent-comment pointed out - that C can't be parsed without a symbol table. Like the example on wikipedia:
A * B;
Which either represents a multiplication or a pointer of type A* to B, depending what the symbol table looks like. That means parsing C is impossible without these hacks, and you need to basically parse the whole file to build up this information.
A lot text editors which only support grammars can't parse this properly, there are a ton of buggy C parsers in the wild.
The issues that led to this were completely avoidable, and many languages like Pascal (which was more or less its contemporary), Go or Rust did avoid them. They don't lead to the language being more powerful or expressive.
Calling it the 'worst' might be hyperbole, but given how influential C-style syntax has become, and how much C code is out there, these issue have affected a ton of other languages downstream.
Re: Crafting Interpreters
#57Earlier quoted context omitted.
Visitor is heavy of code pattern that can be replaced by elegant, readable switch with exhaustive check, so all operations available by "Kind" enum are covered.
Roslyn has visitor pattern combined with the 'Kind' enumeration you mentioned. You can either choose to visiti a SyntaxNode of a certain type, or override the generic version and decide what you want to do based on that enumeration.
C# doesnt have exhaustive switch over enums.
It needs to get "closed enum" lang. feature.
Re: Crafting Interpreters
#58Earlier quoted context omitted.
Roslyn has visitor pattern combined with the 'Kind' enumeration you mentioned. You can either choose to visiti a SyntaxNode of a certain type, or override the generic version and decide what you want to do based on that enumeration.
C# doesnt have exhaustive switch over enums. It needs to get "closed enum" lang. feature.
Exhaustive enums (or type switches) are not a requirement, and are infact harmful - imagine if they add a new kind of syntax node to the language, now your analyzer no longer compiles unless you add a default case - which is very easy to add in C# as well.
Re: Crafting Interpreters
#59Earlier quoted context omitted.
Roslyn has visitor pattern combined with the 'Kind' enumeration you mentioned. You can either choose to visiti a SyntaxNode of a certain type, or override the generic version and decide what you want to do based on that enumeration.
C# doesnt have exhaustive switch over enums. It needs to get "closed enum" lang. feature.
[dead]
Re: Crafting Interpreters
#60Earlier quoted context omitted.
C# doesnt have exhaustive switch over enums. It needs to get "closed enum" lang. feature.
Exhaustive enums (or type switches) are not a requirement, and are infact harmful - imagine if they add a new kind of syntax node to the language, now your analyzer no longer compiles unless you add a default case - which is very easy to add in C# as well.
Unless you add default... or handle such case, as expected.
Ofc you can use this feature wrong and abuse default case, but in general this is very good since it prevents you about missing places to add handling and screams at you at comp time instead of runtimr