Typo in the title as well - although I like the idea that a programmer in the future will search for a contemporary feature called a 'compiler frond' and happen upon this discussion.
Eh, users here just like to find things to complain about. If you didn't have some little typos, the thread would just be bikesheding. And, too much care and you'll never share.
It is a hobby project anyway, it doesn't need to be perfect, and it was good to share either way. People are clearly interested!
People making comment, even about typos means that people find the project interesting enough to read it and try to write a helpful comment. This is a great first topic in HN.
Ohhhh, a transpiler is fantastic. It means I could use C23 + extensions and still use VC as a backend when I have to. (One C codebase I work on has to build on older VC, too, which means accepting obnoxious limitations.)
EDIT: I see it has an option to target C99, but I wonder if it's sufficiently constrained C99 to support VC's not-quite-C99-hah-hah dialect of C. I'll have to try it at some point.
Yes, I'm aware. But a friend has to support very old VC and Windows. Don't ask. Point is that Microsoft's failure to support C99 a decade ago is still annoying.
But it was also required for, e.g., building supported kernel modules. It ended up imposing on others. It was cheap for MSFT, I get that, and this is life, but I also get to point out that this happened.
this is really cool, i want to do something related, make a language like vala.
what is the biggest difficulty in this type of transpiler in your short journey?
German by chance? Hopefully you're okay with language corrections :)
I live in Germany now and I often hear "funny" (lustig) used where "fun" (Spaß, used in English as an adjective too - something like spaßig but that's still considered "funny") should instead be used. Just a tip!
This project is awesome, by the way. Thanks for posting it.
My goal with the transpiler is not only the transpiler, although my front end had to be created differently of an normal compiler and preserve more tokens that could be discarded during the compilation. This also can be useful for a tool that does refactoring.. like renaming variables etc.. so in any case it it useful.
The new C23 language has a lot of features that makes your code not compile in previous C versions like attributes digit separators etc.. Someone may wants to create a new project in C23 and soon regret because the users of the code may need C99. This would be one use case, you can create a C23 code and have C99 versions of the same base code.
Unfortunately my transpiler is not "production ready" yet and I don't have IDE plugins etc.. that is required to make the tool more productive.
The other advantage, if we had a production ready transpiler with a IDE support etc.. it that we could use C23 and compile to C99 without having to wait for compilers like msvc to implements the standards.
Also some experimental features (like defer) can be used and you can distribute your code in standard C99. We have more freedom to use wherever we want and distribute a "readable" C99 code.
By the way most of the C transpilers or compilers generates C code only for immediate compilation. CFront was like that.
My transpiler have two modes one is for direct compilation and other is to distribute generated code.
> The new C23 language has a lot of features that makes your code not compile in previous C versions like attributes digit separators etc.. Someone may wants to create a new project in C23 and soon regret because the users of the code may need C99.
> Why do I want a transpiler to take C23 code and convert it down to C99 code?
Because you are required to use Visual Studio or some compiler that barely even does C99/C11.
> If I was interested in using the C23 features, wouldn't I use a C23-ready compiler?
Yes, but maybe you can't guarantee a C23-capable compiler on all the platforms you care about, or maybe you are required to support VS/VC.
> That said... I do wonder how long it will be until ARM and GCC have a C23 toolchain - or did I just answer my own question?
You did :)
Transpiling is just a very useful idea. Sure, why even bother, the world should be perfect already! But the world isn't. And anyways, transpiling is a very cool idea. If you have time and funding (e.g., maybe you're a graduate student), then you might build it. If you don't have the time and funding you might wonder why even bother, except maybe you have the need and then you get the funding? Even if you don't have the time or funding, you might make an idea you care about into a hobby. So there's many reasons why one might want to build a transpiler.
In another thread we were talking about transpilers for SQL. There the motivation is much stronger and clearer than here, but it's of the same sort: portability. In the case of SQL there's so much variation across RDBMSes that if you must support more than one, you'll quickly wish you had a transpiler for some dialect, or even for an alternative query language.
Another thing is that a transpiler won't need to do much analysis or optimization, so it can be fairly simple compared to a full compiler, but! a transpiler can be much less ambitious than -and a great starting point for- constructing a compiler.
I should spend some more time reading through what you have, but can you answer: what parts of this should I be looking at if I just want something to generate an AST for C99 (no transpiling needed)?
There’s some source analysis I’d like to do (on student C code) and right now I’m considering the (python-based) C parser in CFFI, but your’s might be more complete?
You can also use pycparser[0]. It is fully compatible C99, but be careful it doesn't support gnu extensions (like attributes, #indent, asm() ...). You can however work around most of them by -D defining them to empty macro in the argument.
Right, pycparser is what CFFI uses. I’ve seen some really cryptic error messages when it tries to process some of my C header files (since worked around), and I’m curious what else is out there. The ability to preserve info about formatting that the OP noted is especially interesting.
As long as we’re on this tangent, here’s the challenge I’m facing with automated analysis of student code: from foo.c make bar.c which is identical to foo.c except that comments have been turned into spaces. I think this is annoyingly non-trivial.
To remove comments from source all you need is a tokenizer.
You don't need all the tokens, just the "preprocessor tokens". For instance
literal strings, ppnumbers ...
Then /comments/ can be replaced with 1 space and //comments by \n
Multi-line comments would need to be turned into multiple blank lines, but yes, thank you for pointing out that I've been over-thinking this. I will look into what is the path of least resistance for this tokenizer-based transformation.
It isn't CMake's job to do this. Just have it pass a flag to your compiler to use a custom pre-processor (--no-integrated-cpp -B<path>). Should work... hopefully. Might also have to pipe through the preprocessor again since OP's most likely won't be processing #includes and such
One of its unique features is the transpiler that can generate readable code, preserving macros and formatting.
See it online: http://thradams.com/web3/playground.html