www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ImportC + metaprogramming?

reply Steven Schveighoffer <schveiguy gmail.com> writes:
I was just watching Brian's talk on OpenBSD porting to D, and in the 
comments on Youtube, someone asked about how ImportC might help with 
avoiding having to port headers.

His response contained this truth nugget: "IIRC, importC goes directly 
from C source to D AST, so importC would need to gain the ability to 
rewrite its AST back into D source code."

One of the biggest problems with ImportC as everyone knows is the 
preprocessor. One thing that absolutely sucks is if you have something like:

```c
#define foo 42
```

This information is lost forever once you preprocess the file. But you 
can expose this by converting this to an enum! How to do it?

Well, this won't work:

```c
enum foo = foo; // translates to `enum 42 = 42`
```

So you have to come up with a *different* name, and then expose that. 
This really sucks, and I believe projects like dstep translate the thing 
to A D enum, and avoid using the preprocessor at all. But in the world 
of C, there's not an easy way to do this without coming up with some 
horrific naming mangle.

I thought, maybe if you import the C file, then you can introspect 
something from D! But no, there is nothing left to introspect once the c 
preprocessor is done. For actual functions, etc. that would work great, 
but not #defines.

But Brian's statement got me thinking -- what if we allowed just a 
*little bit* of the D camel's nose into the tent? Like some escape that 
could allow the D compiler to actually inject some meta into the AST 
while preprocessing?

What if we had something like a .cm or something file, which is treated 
like C + metaprogramming (e.g. __traits)? Then we can use a specialized 
preprocessor to be part of the compilation step that allows assisting 
with the header "porting".

Is this crazy talk, or does it make any sense?

-Steve
Jan 15 2022
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
What I think would be cool is to have the preprocessor be a D 
object, then import c actually be able to run on strings; what I 
call mixinc:

http://dpldocs.info/experimental-docs/mixinc.html

Your specialized preprocessor idea has some overlap.
Jan 15 2022
prev sibling next sibling parent Brian Callahan <bcallah openbsd.org> writes:
On Sunday, 16 January 2022 at 02:28:04 UTC, Steven Schveighoffer 
wrote:

 His response contained this truth nugget: "IIRC, importC goes 
 directly from C source to D AST, so importC would need to gain 
 the ability to rewrite its AST back into D source code."


I am glad I remembered correctly in answering gad's question :)

I still manually sync headers as I notice headers that need 
updating. I most recently synced socket.d just the other day. If 
anyone comes up with a better strategy, please let me know I will 
be the first to try it out.

~Brian
Jan 15 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
In this PR,

https://github.com/dlang/druntime/pull/3670

I added the ability for an ImportC file to import a D file. The initial purpose 
was so that core.stdc.stdarg could be imported to support variadics in C, 
without reimplementing them.

I realized that this actually works - ImportC code can call D code! even use D 
templates!

So then I got to thinking "what the hell have I unleashed?"

I think I just destroyed dtoh.
Jan 16 2022
next sibling parent Daniel N <no public.email> writes:
On Sunday, 16 January 2022 at 08:13:37 UTC, Walter Bright wrote:

 In this PR,

 https://github.com/dlang/druntime/pull/3670

 I added the ability for an ImportC file to import a D file. The 
 initial purpose was so that core.stdc.stdarg could be imported 
 to support variadics in C, without reimplementing them.

 I realized that this actually works - ImportC code can call D 
 code! even use D templates!

 So then I got to thinking "what the hell have I unleashed?"

 I think I just destroyed dtoh.


wow, impressive insight!
Jan 16 2022
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Sunday, 16 January 2022 at 08:13:37 UTC, Walter Bright wrote:

 In this PR,

 https://github.com/dlang/druntime/pull/3670

 I added the ability for an ImportC file to import a D file. The 
 initial purpose was so that core.stdc.stdarg could be imported 
 to support variadics in C, without reimplementing them.

 I realized that this actually works - ImportC code can call D 
 code! even use D templates!

 So then I got to thinking "what the hell have I unleashed?"

 I think I just destroyed dtoh.


So we inject this into all C files before compilation? Or modify 
all the system headers?
Jan 16 2022
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/16/22 9:34 AM, max haughton wrote:

 On Sunday, 16 January 2022 at 08:13:37 UTC, Walter Bright wrote:

 In this PR,

 https://github.com/dlang/druntime/pull/3670

 I added the ability for an ImportC file to import a D file. The 
 initial purpose was so that core.stdc.stdarg could be imported to 
 support variadics in C, without reimplementing them.

 I realized that this actually works - ImportC code can call D code! 
 even use D templates!

 So then I got to thinking "what the hell have I unleashed?"

 I think I just destroyed dtoh.


 
 So we inject this into all C files before compilation? Or modify all the 
 system headers?


The current expectation with ImportC is first you have to write a C file 
which imports what you want to convert, run it through the preprocessor, 
and then you compile it with D.

So it would go in that shim.

-Steve
Jan 16 2022
prev sibling next sibling parent max haughton <maxhaton gmail.com> writes:
On Sunday, 16 January 2022 at 08:13:37 UTC, Walter Bright wrote:

 In this PR,

 https://github.com/dlang/druntime/pull/3670

 I added the ability for an ImportC file to import a D file. The 
 initial purpose was so that core.stdc.stdarg could be imported 
 to support variadics in C, without reimplementing them.

 I realized that this actually works - ImportC code can call D 
 code! even use D templates!

 So then I got to thinking "what the hell have I unleashed?"

 I think I just destroyed dtoh.


If I want to call D from C it still sounds like I would be using 
dtoh.
Jan 16 2022
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/16/22 3:13 AM, Walter Bright wrote:

 In this PR,
 
 https://github.com/dlang/druntime/pull/3670
 
 I added the ability for an ImportC file to import a D file. The initial 
 purpose was so that core.stdc.stdarg could be imported to support 
 variadics in C, without reimplementing them.
 
 I realized that this actually works - ImportC code can call D code! even 
 use D templates!


Interesting!


 
 So then I got to thinking "what the hell have I unleashed?"
 
 I think I just destroyed dtoh.


Hm..., how does this help with preprocessor defines?

What I'm looking for is a way to write a .c (or .cm or whatever) file 
that does:

```c
#include "mylib.h"

// rewrite mylib #defines as enums here
...
```

For use with ImportC.

And I don't know how to do that. There's no introspection capabilities 
because the preprocessor isn't part of the D toolchain. Even doing it in 
C is nearly impossible without renaming the thing. You can't use mixin 
facilities, so using a D import doesn't work (plus it needs explicit 
template parameters, which isn't valid C syntax).

Do you have a plan for this?

-Steve
Jan 16 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2022 8:36 AM, Steven Schveighoffer wrote:

 Hm..., how does this help with preprocessor defines?


Unfortunately, it doesn't.



 // rewrite mylib #defines as enums here



 Do you have a plan for this?


Not at the moment.
Jan 16 2022
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 16 January 2022 at 08:13:37 UTC, Walter Bright wrote:

 In this PR,

 https://github.com/dlang/druntime/pull/3670

 I added the ability for an ImportC file to import a D file. The 
 initial purpose was so that core.stdc.stdarg could be imported 
 to support variadics in C, without reimplementing them.

 I realized that this actually works - ImportC code can call D 
 code! even use D templates!

 So then I got to thinking "what the hell have I unleashed?"

 I think I just destroyed dtoh.


Unleashed the dragon
Jan 16 2022
parent max haughton <maxhaton gmail.com> writes:
On Monday, 17 January 2022 at 07:11:08 UTC, bauss wrote:

 On Sunday, 16 January 2022 at 08:13:37 UTC, Walter Bright wrote:

 In this PR,

 https://github.com/dlang/druntime/pull/3670

 I added the ability for an ImportC file to import a D file. 
 The initial purpose was so that core.stdc.stdarg could be 
 imported to support variadics in C, without reimplementing 
 them.

 I realized that this actually works - ImportC code can call D 
 code! even use D templates!

 So then I got to thinking "what the hell have I unleashed?"

 I think I just destroyed dtoh.


 Unleashed the dragon


The dragon has no flame. If you use this how do you use (say) a 
slice? dtoh does this automatically by providing a templates 
struct, what does this do on the C side?
Jan 17 2022
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
A different solution I had thought up was that maybe we could have 
expressions act in a C scope.

Then when you preprocess C you export the macros, wherever you import if 
a specific identifier appears boom! evaluate the C stuff instead.
Jan 16 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
I can now verify that ImportC can import D files, and instantiate templates
from 
those files!
Jan 17 2022
parent jummules <jimmydicson gmail.com> writes:
Thanks for this solution! I will try to use this code for my 
project.
Jan 19 2022