4 ms·
Once you have an intuition, you just write the parser yourself. I'm not a fan of parser generators. I find them restrictive. It is also notable most mainstream
by 3cats-in-a-coat 3y ago
Once you have an intuition, you just write the parser yourself.
I'm not a fan of parser generators. I find them restrictive. It is also notable most mainstream languages do not use tools like YACC, they have "handmade" parsers and compilers.
This may seem like I'm suggesting pie-in-the-sky approach from the ground up for something that may never need such control. Could be. But I don't feel like learning YACC is easier than learning how to parse anything in general. I think YACC and so on are holding people back from truly expressing themselves with custom languages, and after all that was the whole point of them writing a language or wasn't it?
- 29athrowaway 3y agoSo let's say, you decide to create your own programming language, now you can automatically afford to do as much work as the organizations behind mainstream programming languages? Organizations with thousands of contributors, funding, etc.? Now, let's omit that for a moment. Let's say that after having implemented your language after years of work, now for some reason you got 1 prospect user. That person will ask you about: syntax highlighting, linting, code navigation, testing, packaging, documentation, operating systems/architecture support, etc. Who is going to contribute all that if you are busy writing everything by hand? Unless you have as much time as Terry Davis, you are better off starting by piggybacking on something that exists. Then, once you have an idea that scales, you can convince other people to help you and have a successful project. Then you can have a viable ecosystem that people can comfortably join.
- jstimpfle 3y agoThe real problem about parsing is not parsing the formal grammar. It's deciding what to store about the parsed input (CST to AST) and designing the ancillary datastructures for further processing, integrating the parser with the rest of the application, etc. The real problem about building a compiler is everything else but not parsing. Parsing is the easiest part. Once you've written a view recursive descent parsers you will probably agree. The parser for syntax highlighting is probably a different one than the parser for AST generation and compilation. So is a parser for batch compilation different to one for incremental compilation. Even the syntax might be different.
- laxd 3y ago.... "syntax highlighting, linting, code navigation, testing, packaging, documentation, operating systems/architecture support" This has nothing to do with using a parser generator or not.
- 29athrowaway 3y agoIt has to do with having time to spend in creating a convenient development experience and picking your battles.
- laxd 3y agoThat's agreeable. We seems to disagree on how to achieve that ideal - on the specific point of whether to use a parser generator or not. The correct answer is not :)
- 29athrowaway 3y agoWhat you consider correct or not is simply an opinion.
- 3cats-in-a-coat 3y agoUsing YACC doesn't give you magical integration with IDEs, operating systems, testing, documentation and so on. I feel as if you took my specific comment about parsers (which are not hard to write at all, few hundred lines of code for a moderately complex language) in an inappropriately general way as in "don't use anything for anything when doing anything".
- Tade0 3y agoI'm not well versed in this space. Are you suggesting designing a language without specifying a formal grammar?
- jstimpfle 3y agoOne does not preclude the other. Most languages that lend themselves to hand-parsing via recursive descent are probably LL(1). Syntaxes that are easy to parse via recursive descent are probably also the ones that are easiest to parse for humans.