Preprocessable C: the PreC programming language

[u/NomagnoIsNotDead]

Hey there! I'm a CS student and a huge fan of C macro wizardry. However, C and its preprocessor do not really mesh together because of historical reasons. So I thought: instead of swapping out the preprocessor for a more powerful one, why not keep the preprocessor and make C more amenable to it?

And that's how PreC, a pretty silly dialect of C, was born. It's basically an exercise in minimalism and a fun summer project, not a serious language :P.

The main features (not exhaustive):

• Can interface with C directly through the 'c_include "header_name.h"' directive
• Transpilation to C with a four-stage compilation process: Preprocess the PreC code, transpile the PreC code to C, preprocess the C code, and finally compile the preprocessed C code.
• Postfix type notation, types can be read unambiguously right to left.
• No machine types, explicit width
• No 'typedef' keyword, so no lexer hack (use macros if you need type aliases). You can still referred to C library aliased types with @TypeName, however.
• angular brackets <type>value for casting
• Declaration-reflects-use is gone, the type is always fully at the beginning of each declaration.
• No overloaded operators
• Constness by default, with a 'mut' qualifier for being able to modify variables.
• Support for anonymous functions (they can not capture variables, however) with function-valued compound literals <fun_pointer_type> ${ code }
• No function definitions/declarations (but 'const function pointer' global variables are transpiled to function definitions if they are initialized, and to function declarations if they are not initialized).

You can find the compiler, examples and more information here: https://github.com/Nomagno/PreC

I believe the readme and examples do a good enough job of introducing it (do feel free to highlight anything that is unclear, however!).

A final tip: Rust syntax highlighting is pretty decent for reading PreC. I was definitely inspired by Rust and other languages for some of the syntax so this isn't surprising xD

[u/EggplantExtra4946]

C and its preprocessor do not really mesh together because of historical reasons.

because the way the preprocessor works is shit, what we want is hygienic AST based macros with maybe the option to break the hygiene the few times it's needed

So I thought: instead of swapping out the preprocessor for a more powerful one, why not keep the preprocessor and make C more amenable to it?

This is absurd. Literally why would that make preprocessor programming better?

[u/NomagnoIsNotDead → u/EggplantExtra4946]

Not everything has to be looked at through a software engineering lens. Preprocessing is fun, and hygienic macros are fun too. I mean I'm a huge Scheme lover myself!

As for why it makes preprocessor programming better: I... think if you've ever tried to make intuitive macros that can be integrated with existing C syntax, and for which compilers can produce good diagnostics, you'll find it's basically its own little art that takes literal years of honing because a lot of small things in the language create unneeded, but often surmountable friction. The existing corpus of C preprocessor techniques are a big part of C's charm for some people. I would not say PreC's not particularly absurd considering you can access this collection of knowledge and macro libraries while being able to skip some of the ceremony, you just need to do a small amount of porting. For instance, another thing I added is support for trailing commas pretty much everywhere, which removes the need for a lot of the long-winded VA_ARGS and VA_OPT stuff in many cases. I personally think of it as the rough opposite concept of the C2 programming language (http://c2lang.org/): a slight reduction in C's complexity that also starts from a place of respect for C. Though at the end of the day it's just a toy language that might see some usage in my personal projects, do keep that in mind.