Playing with 'minimal' ways to add templates/generics/reflection to C has become a bit of a dumb hobby of mine (in this case shared/enabled by Akshay!).
Gamma was an experiment in templates without having to parse C. This led to some big annoyances that I guess aren't mentioned on that site but are in the PagedOut page[1]: when you instantiate a template "bar::[struct foo]" Gamma does a pretty bad job of knowing to copy the definition of "struct foo" (and all type definitions that "struct foo" depends on) from the caller into the template before compiling the instantiated template. (It gets even worse with circular dependencies, e.g., a "struct tree_node" that contains a "list::[struct tree_node]".)
More recently I've been writing MaC[2], which solves those problems by fully parsing the "header file" for each template. So it knows about all of the types in the program and can copy them between template instantiations as needed, but in the "main body" of the template you can use arbitrary GNU-C features. This has been a lot more reliable. As a test program for it I'm currently in the middle of writing an LR[k] parser generator[3] in MaC.
The big thing that gets annoying about all of these "don't-parse-the-code" approaches is there's no good way to do type inference. So you can't do multiple dispatch, e.g., have "print(x->foo(bar));" forwarded to the 'right' print function based on the type of its argument. (Actually, I've experimented with doing dynamic dispatch based on DWARF information, but that's a huge can of worms itself!)
I used to very down on C++ but have stopped caring quite so much... Just using C++ and restricting oneself to templates seems like a better bet than this. Or you could use D and have a language whose template experience is much better than C++'s...
Any language this is going to need debug info eventually. One could step through the generated C code, but this is much less pleasant than stepping through the original source.
For me, it was just to have some fun seeing whether you can get the convenience of generics in C without blowing up the size of a "minimal standards-compliant compiler." E.g., Chibicc[1] is only a few thousand lines of code; adding Gamma to that would not blow it up by much. There's something aesthetically pleasing about knowing I can read the whole thing in a few days. Nothing like that is possible for C++ (or D?) AFAIK.
But yes --- for a real project I would absolutely recommend someone use D over this !
Why is the Type T notation needed. Just make T the generic type by default and allow using it instead of int, float etc. Is that not possible? This looks like a lot of syntactic noise. Not as bad a c++, but not far from it.
Playing with 'minimal' ways to add templates/generics/reflection to C has become a bit of a dumb hobby of mine (in this case shared/enabled by Akshay!).
Gamma was an experiment in templates without having to parse C. This led to some big annoyances that I guess aren't mentioned on that site but are in the PagedOut page[1]: when you instantiate a template "bar::[struct foo]" Gamma does a pretty bad job of knowing to copy the definition of "struct foo" (and all type definitions that "struct foo" depends on) from the caller into the template before compiling the instantiated template. (It gets even worse with circular dependencies, e.g., a "struct tree_node" that contains a "list::[struct tree_node]".)
More recently I've been writing MaC[2], which solves those problems by fully parsing the "header file" for each template. So it knows about all of the types in the program and can copy them between template instantiations as needed, but in the "main body" of the template you can use arbitrary GNU-C features. This has been a lot more reliable. As a test program for it I'm currently in the middle of writing an LR[k] parser generator[3] in MaC.
The big thing that gets annoying about all of these "don't-parse-the-code" approaches is there's no good way to do type inference. So you can't do multiple dispatch, e.g., have "print(x->foo(bar));" forwarded to the 'right' print function based on the type of its argument. (Actually, I've experimented with doing dynamic dispatch based on DWARF information, but that's a huge can of worms itself!)
[1] https://pagedout.institute/download/PagedOut_007.pdf#page=44 [2] https://lair.masot.net/mac/ [3] https://lair.masot.net/git/mac.git/tree/examples/lrk (sorry about the unreadable color scheme, still tuning it ...)
What's the use case for a language like this?
I used to very down on C++ but have stopped caring quite so much... Just using C++ and restricting oneself to templates seems like a better bet than this. Or you could use D and have a language whose template experience is much better than C++'s...
Any language this is going to need debug info eventually. One could step through the generated C code, but this is much less pleasant than stepping through the original source.
I also wonder how name mangling is handled?
For me, it was just to have some fun seeing whether you can get the convenience of generics in C without blowing up the size of a "minimal standards-compliant compiler." E.g., Chibicc[1] is only a few thousand lines of code; adding Gamma to that would not blow it up by much. There's something aesthetically pleasing about knowing I can read the whole thing in a few days. Nothing like that is possible for C++ (or D?) AFAIK.
But yes --- for a real project I would absolutely recommend someone use D over this !
[1] https://github.com/rui314/chibicc
Totally fair. Just wondering if there was some specific motivation for being able to do this... "For fun" is valid, IMO. ;-)
Why is the Type T notation needed. Just make T the generic type by default and allow using it instead of int, float etc. Is that not possible? This looks like a lot of syntactic noise. Not as bad a c++, but not far from it.
If you need more than just T, then you could do T1, T2, ..., Tn as well.