4 ms·
As described, you’ll almost definitely need to write a parser. However, if your type system is very similar to C’s you may be able to just lower from the AST to
by lucozade 9y ago
As described, you’ll almost definitely need to write a parser. However, if your type system is very similar to C’s you may be able to just lower from the AST to C and let it worry about semantic analysis and code generation.
The biggest loss is that a lot of error and debug info will be relative to the C rather than your language. This means the user will be exposed to the internals.
Probably the biggest win, is that it’s almost trivial to integrate C, and potentially C++ libraries into your language. This has been hugely beneficial to Nim, for example. They have written a full front end though so they don’t have the error issue above.
Like most things it’s a trade off.
- humanrebar 9y agoNot mentioned in that list of downsides is that you need to at least embrace the calling conventions, threading models, and memory models that C supports, at least for the flavors you target. > The biggest loss is that a lot of error and debug info will be relative to the C rather than your language. This means the user will be exposed to the internals. In other words, sometimes the end user has to debug a bunch of code they didn't write. I wouldn't underestimate how much a pain this can be. > Probably the biggest win, is that it’s almost trivial to integrate C, and potentially C++ libraries into your language. Again, subject to adhering to threading models, etc. If you're writing a language as a hobby, this may not be a big concern, but at scale, someone will be using memcpy or memory barriers or thread-local memory somewhere. It is certainly possible to support those use cases, but I'd be careful about overstating how trivial that is.