3 ms·
Anyone can do whatever they want, and if you do want to write a parser in C this may be a good guide for you. But it's hard to understand the benefit to writing
by eatonphil 5y ago
Anyone can do whatever they want, and if you do want to write a parser in C this may be a good guide for you. But it's hard to understand the benefit to writing a language frontend in C, generally speaking. (An obvious exception might be if you are writing one of the first languages for a new architecture/operating system or one where only a C compiler exists.)
If you are writing a compiler, you'll just be emitting some other language anyway so the parser/emitter being in C doesn't really give you anything even if you are emitting C.
If you are writing an interpreter and you want performance, you're going to have to emit bytecode and have a bytecode interpreter. Wanting your bytecode _interpreter_ to be in C could make sense but your frontend could just emit the bytecode to a file and your interpreter written in C could read from that file.
It's a handwritten parser too so it's not like you picked the language so you could use a certain complex or nice parsing library.
And it's not like the performance (or binary size) of the parser/emitter typically matters so much that you need even that part to be so much faster (or smaller) than a parser/emitter in Go/Java/C#/whatever.
The overhead to writing C makes it a less friendly introduction to the topic if you have never written a compiler or interpreter (or parser, specifically) before.
Again, you can do what you want. And if you must do it in C, you will probably value any posts like this. Just wanted to throw out reasons you may not want to do this.
- arkj 5y ago> But it's hard to understand the benefit to writing a language frontend in C, generally speaking. The advantage of writing in C is that the language provides very little “high” level features. All you have is just functions and memory so you end up doing everything which is a laborious process but rewarding to the mind especially if you are someone who never did low level programming.
- fishmaster 5y ago> The overhead to writing C makes it a less friendly introduction to the topic if you have never written a compiler or interpreter (or parser, specifically) before. That's true and was my first thought. C seems like an arcane choice for an introduction course.
- david2ndaccount 5y agoC is a simple language and at least used to be a language almost everyone knew. I don’t know why they’re writing the parser using globals though instead of passing a pointer to a parser state struct.
- arcticbull 5y agoC is an incredibly complex language, it just appears simple. It's simple to get started and incredibly hard to do correctly, like skiing.
- retrac 5y agoNo, those things are not a complexity of C. They're just complex to implement at a lower level. They're complicated in any language, often, if approached at the level C provides. You have to hand-hold the machine through it. A C-like implementation of linked lists in an array of memory using pointers, for example, looks just as bad if written in that way in unsafe {} Rust, or even some mutating thing in Haskell. You can do that if you want, but you don't have to. Those languages allow you to abstract that away very quickly (often already pre-abstracted for you with default approaches). That's what people mean when they say C is simple. Plain and simple. Minimal. You have to do much of the heavy lifting.
- arcticbull 5y agoRespectfully disagree. A language that fails to adequately provide safeguards to a user is a complex language because it forces all the complexity of dealing with the underlying machine onto the user. These are things a user needs to know to be effective in the language, which in turn makes using the language complex. It's a deceptively simple language. C is complex because of what it doesn't do, not what it does. That's IMO worse.
- retrac 5y agoIt's not so much that we're disagreeing as arguing different points about the language, I think. You are right that it is not a simple language to use, in many ways. Archaic, unnecessarily complicated to implement many standard approaches, and very repetitive. The header system is just the wrong approach. Etc. I wouldn't pick it for the main language for a new project, if at all avoidable personally. It's very easy to implement, though. A compiler fits in 32 kilobytes of RAM on some architectures. Only a handful of control structures. Limited types. That's the sense of simple that I meant, and which most people meant. It's not a compliment. It's a neutral observation. It's actually C's greatest weakness. It's too simple.
- foxfluff 5y agoBrian's choice to use C is perfectly well justified: "I am thinking that we should choose C to implement our PL/0 compiler. Eventually we will want to have this compiler run on many different platforms, including Unix, MS-DOS, and potentially even CP/M. C is a language that will run on every platform I would want to run our PL/0 compiler on, so C works for me. C also requires no special setup so our usual development platform of vim on OpenBSD will work just fine. Finally, it will help with bootstrapping the self-hosting version of the PL/0 compiler, since we in theory could natively compile the C implementation on our target platform then use that to compile the PL/0 implementation, also on the target platform." The reader may learn something from these posts whether they choose to write a compiler in C or not.
- eatonphil 5y agoI don't mean to debate Brian's choice (your quote shows it does fall into my exception anyway) but mention to readers here why they may be more interested in following guides on compiling/interpreting implemented in other languages than C.
- fishmaster 5y agoC is actually a huge disadvantage here for me, since I have no use for it outside of this tutorial which makes it hard to justify learning it on top of learning how a compiler works...