> 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.
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.
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.
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.
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?
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.
14 comments
[ 3.2 ms ] story [ 45.0 ms ] threadVery nice! If only this could work with C++.
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
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()`.
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 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:
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.
Write-only languages, yay.