Lisp macros for C | Hacker News Reader

Lisp macros for C

github.com

113 pointswooby14 comments

> Why? Because a language without macros is a tool: You write applications with it. A language with macros is building material: You shape it and grow it into your application.

Very nice! If only this could work with C++.

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.

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

might be handy sometimes.

`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

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()`.

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.

> 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:

    x = less_than(a, b) ? (a+1) : b;

A proper type inference algorithm can deduce the types of less_than ((int, int) -> bool) and a (int because a+1) and b (int because it must match the other side of the conditional) and x (int). C++ auto could only defer the type of x given the types of less_than, a and 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.

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)

Reply on news.ycombinator.com