3 ms·
> And there's rarely any good stuff on the actual hard problems So what are those hard problems?
by habibur 5y ago
> And there's rarely any good stuff on the actual hard problems
So what are those hard problems?
- sim_card_map 5y agocodegen, optimizations, ast transformations
- dmitriid 5y agoThe actual compilation. Actual programming language design. Types, type inference, function implementations, error handling and recovery, incremental compilation, interfacing with the external world, code generation, fixing problems in code generation tools, CPU architecture concerns... The toy languages that most learning materials make can be parsed with regexps and is definitely not something to spend a lot of time on at the beginning. Because actual parsing problems are never addressed in these materials, and can come later (example of concerns: https://matklad.github.io//2018/06/06/modern-parser-generator.html https://matklad.github.io//2018/06/06/modern-parser-generato...).
- rualca 5y ago> The actual compilation. Actual programming language design. Isn't that intimately tied to parsing? I mean, how do you expect to implement a parser if you have no idea if a specific programming construct can actually be parsed, or what are the implications in compilation time of doing things one way or another?
- dmitriid 5y ago> Isn't that intimately tied to parsing? Not entirely > how do you expect to implement a parser if you have no idea if a specific programming construct can actually be parsed Every construct can be parsed. However, there are significantly more aspects to language design than "parsing programming constructs". For example, C++ header/implementation split with no real module system affects compilation orders of magnitudes more than the parsing rules for C++.