Lisp macros for C(github.com)
github.com
Lisp macros for C
https://github.com/eudoxia0/cmacro
14 comments
This is very interesting way to breathe new life into C. I can already think of few places where powerful macros would come in handy and eliminate some pains. On the other hand, I'm not sure if I'd want to read other people's low-level code sprinkled with high-level constructs. Perhaps Nim would serve this purpose better?
> I'm not sure if I'd want to read other people's low-level code
Write-only languages, yay.
Write-only languages, yay.
TIL: You can use typeof(expr) as a type in variable declarations. C has type inference! A plain old C macro like
#define AUTO(var, expr) typeof(expr) var = expr
> C has type inference!
This is only one-way type deduction (similar to C++ `auto` keyword) which isn't really proper two-way type inference. It just copies the type of the right hand side to the left hand side.
E.g. given the following code:
And by "proper type inference" I mean the text book Hindley-Milner unification algorithm from the 1970's, not a more modern variant with traits or type classes and whatnot.
This is only one-way type deduction (similar to C++ `auto` keyword) which isn't really proper two-way type inference. It just copies the type of the right hand side to the left hand side.
E.g. given the following code:
x = less_than(a, b) ? (a+1) : b;
And by "proper type inference" I mean the text book Hindley-Milner unification algorithm from the 1970's, not a more modern variant with traits or type classes and whatnot.
`typeof()` is a common compiler extension, not standard C. (C++11 irritatingly standardized it as `decltype()`).
> [...] irritatingly [...]
Or correctly; it is so common and so different (and incomplete) across implementations, so a new name with the exact semantics has been invented [1].
[1] http://www.stroustrup.com/C++11FAQ.html#decltype
Or correctly; it is so common and so different (and incomplete) across implementations, so a new name with the exact semantics has been invented [1].
[1] http://www.stroustrup.com/C++11FAQ.html#decltype
I understand the reasoning, I just think it's wrong. The point of a standard is to, well, standardize. And each new version of the standard breaks plenty of existing (and strictly standards-compliant!) code, often intentionally.
Now a type deduction operator is never going to come to standard C because any proposal will get buried under endless bikeshedding about whether to call it `typeof()` or `decltype()`.
Now a type deduction operator is never going to come to standard C because any proposal will get buried under endless bikeshedding about whether to call it `typeof()` or `decltype()`.
I'm not sure about C++, but C tries pretty hard not to break code that complies with a previous standard unless it's absolutely necessary, and they put some effort into avoiding breaking common extensions too.
This is why, for example, the language-level boolean type introduced in C99 is `_Bool`, and then you can include a standard header that will typedef it to `bool`. Identifiers that begin with an underscore and an uppercase letter are reserved for the implementation, so no compliant code will be using _Bool anywhere for itself. And since old code won't include `stdbool.h`, there's no conflict if it happens to define its own `bool`.
Given this, it seems like the best approach would be to call it `_Typeof` or similar, with a standard header that does `#define typeof(x) _Typeof(x)` to make it nicer to use.
This is why, for example, the language-level boolean type introduced in C99 is `_Bool`, and then you can include a standard header that will typedef it to `bool`. Identifiers that begin with an underscore and an uppercase letter are reserved for the implementation, so no compliant code will be using _Bool anywhere for itself. And since old code won't include `stdbool.h`, there's no conflict if it happens to define its own `bool`.
Given this, it seems like the best approach would be to call it `_Typeof` or similar, with a standard header that does `#define typeof(x) _Typeof(x)` to make it nicer to use.
GCC and Clang(since 2016) have "__auto_type" extension for C which does a similar thing.
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Very nice! I like using `auto` when writing C++ and miss it when writing Objective-C. I could use Objective-C++, of course, but that has its own problems. I'll have to keep this in mind.
Thanks for sharing. The documentation is well done, looking forward to checking out the code.
This way of adding metaprogramming to C does not improve performance. The compiler will still be unable to inline the comparisons in the qsort example. C++ will continue to be much faster.
It does. It's just no one has come around to write a qsort in macros yet. (And only then the comparison would be fair)
Very nice! If only this could work with C++.