Hi.

In the past years, I've worked on a type inference technique that can underlie — what I believe is — a nice implementation of generics in C; at https://ltcmelo.com/n2698.pdf you'll find a (draft) proposal that I wrote for it, and at http://www.genericsinc.info a prototype implementation.

What do you think about it? I'm looking for constructive feedback.

Regards,
Leandro

On Monday, July 31, 2023 at 5:49:57 AM UTC-7, Leandro T. C. Melo wrote:
> Hi.
>
> In the past years, I've worked on a type inference technique that can underlie — what I believe is — a nice implementation of generics in C; at https://ltcmelo.com/n2698.pdf you'll find a (draft) proposal that I wrote for it, and at http://www.genericsinc.info a prototype implementation.
>
> What do you think about it? I'm looking for constructive feedback.

Interesting. I appreciate the implementation so that I can see the code generated. One of the things I like about C is that you see what you get. There isn't any hidden code (mostly). The existing C11 _Generic, while hiding a bit, at least has a single location that you can look at to find out which actual function is called. And you can use existing functions if they have the right argument pattern. However, _Generic only handles functions.

You proposal looks nice for the writer of code, but less nice than _Generic for the reader of code. I think that is a step backward for long term code maintenance. The tradeoff here is that you have less code (the generic code) to read to understand something. You also have the possibility of more generic libraries with value rather than pointer members (i.e. not just plain void*) and, if I understood correctly, you should get more type safety (as much as C allows).

For generic structs, this looks pretty interesting. The third example in your demo shows this. Why does it generate a version of the struct with a void* member? Have you used this to build some generic library such as a linked list or binary tree?

Where does the monomorphised code go? This is a standing issue with C++ that has had several implementations, each with some tradeoffs. For a long time, most compilers would not notice identical code being generated and you could get a code explosion.

It seems like the type promotion rules in C are going to be a bit challenging here, but I can't come up with a good example, so take that with a grain of salt.

If these answers are in the proposal, let me know!

Best,
Kyle

On Wednesday, August 2, 2023 at 12:18:38 PM UTC-3, KyleH wrote:
> On Monday, July 31, 2023 at 5:49:57 AM UTC-7, Leandro T. C. Melo wrote:
> > Hi.
> >
> > In the past years, I've worked on a type inference technique that can underlie — what I believe is — a nice implementation of generics in C; at https://ltcmelo.com/n2698.pdf you'll find a (draft) proposal that I wrote for it, and at http://www.genericsinc.info a prototype implementation.
> >
> > What do you think about it? I'm looking for constructive feedback.
> Interesting. I appreciate the implementation so that I can see the code generated. One of the things I like about C is that you see what you get. There isn't any hidden code (mostly). The existing C11 _Generic, while hiding a bit, at least has a single location that you can look at to find out which actual function is called. And you can use existing functions if they have the right argument pattern. However, _Generic only handles functions.
>
> You proposal looks nice for the writer of code, but less nice than _Generic for the reader of code. I think that is a step backward for long term code maintenance. The tradeoff here is that you have less code (the generic code) to read to understand something. You also have the possibility of more generic libraries with value rather than pointer members (i.e. not just plain void*) and, if I understood correctly, you should get more type safety (as much as C allows).
>
> For generic structs, this looks pretty interesting. The third example in your demo shows this. Why does it generate a version of the struct with a void* member? Have you used this to build some generic library such as a linked list or binary tree?
>
> Where does the monomorphised code go? This is a standing issue with C++ that has had several implementations, each with some tradeoffs. For a long time, most compilers would not notice identical code being generated and you could get a code explosion.
>
> It seems like the type promotion rules in C are going to be a bit challenging here, but I can't come up with a good example, so take that with a grain of salt.
>
> If these answers are in the proposal, let me know!
>
> Best,
> Kyle

Hi Kyle,

Thank you for your feedback!

Yes, there's hidden code implied in my proposal; but not so hidden...
in principle, a compiler/plugin could/should offer a command line
option that outputs the non-generic translation; for a plugin, the
output itself would be the non-generic translation so that it's input
to the compiler. This would be analogous to a TypeScript compiler that
outputs JavaScript. How useful would that be to you?

That said, I didn't understand why you consider this reduced
"visibility" a step backwards for code maintenance: for the provider
of generic libraries, I see it as a step forward; for the consumer, I
don't see a significant change in either direction. Could you further
elaborate on this matter?

The void* member in the struct is just an artifact of the
implementation, it can be eliminated. I've started porting non-generic
implementations of data-structures from popular libraries, but I
haven't yet finished.

In regards to the monomorphized code, I think that my first comment
might have addressed your question. Yet, I believe that it's
straightforward to detect (and discard) duplicate code.

Type promotions can be tricky for type inference in general, but with
the technique that I brief on the proposal they can be handled in the
same way that the conversions between int and double (which are
implemented in the prototyp) are handled.

Sorry for taking so long to reply.

Kind regards,
Leandro