www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ImportC can now automatically run the preprocessor

reply Walter Bright <newshound2 digitalmars.com> writes:
As https://github.com/dlang/dmd/pull/14121 has been merged, the following 
#ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

It's been a longer and windy-er road than I'd anticipated, but isn't that the 
way all software projects work?

Next up:

1. passing dmd command line arguments to the preprocessor

2. capturing the #define macro dump from the preprocessor, so it can be mined 
for macros that can be translated to D symbols (anticipating leveraging Atila's 
great dpp work on this)
May 14 2022
next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 [...]
 2. capturing the #define macro dump from the preprocessor, so 
 it can be mined for macros that can be translated to D symbols 
 (anticipating leveraging Atila's great dpp work on this)


Item 2 is very interesting! About 10 years ago, when I was just 
learning, I was thinking how can I make a feature like #define in 
D.

SDB 79
May 14 2022
prev sibling next sibling parent reply forkit <forkit gmail.com> writes:
On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 ...

 It's been a longer and windy-er road than I'd anticipated, but 
 isn't that the way all software projects work?
 ...


Well...I'm not aware of any software projects where someone wakes 
up one morning, with a thought bubble, and then decides to submit 
a PR, marked as 'Trivial', that adds a C compiler insider an 
already existing compiler for a different language.

https://github.com/dlang/dmd/pull/12507/

The long, windy road 'could' have been anticipated.

I certainly anticipated it when I read that PR.

It'll be a long, windy road ahead to, for anyone having to 
maintain projects that explicitly, actively, encourage you to 
combine different languages.
May 14 2022
next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Sunday, 15 May 2022 at 01:00:14 UTC, forkit wrote:

 On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 ...

 It's been a longer and windy-er road than I'd anticipated, but 
 isn't that the way all software projects work?
 ...


 Well...I'm not aware of any software projects where someone 
 wakes up one morning, with a thought bubble, and then decides 
 to submit a PR, marked as 'Trivial', that adds a C compiler 
 insider an already existing compiler for a different language.

 https://github.com/dlang/dmd/pull/12507/

 The long, windy road 'could' have been anticipated.

 I certainly anticipated it when I read that PR.

 It'll be a long, windy road ahead to, for anyone having to 
 maintain projects that explicitly, actively, encourage you to 
 combine different languages.


That depends on the nature of the combination.

I will likely never compile a C dependency with ImportC directly, 
and I will definitely never import a D module into a C project, 
but I have already used ImportC for some things and it really 
isn't that complicated either in implementation or praxis.

ImportC should've really happened 10 years ago.
May 14 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2022 7:12 PM, max haughton wrote:

 I will likely never compile a C dependency with ImportC directly, and I will 
 definitely never import a D module into a C project


Consider that one thing ImportC enables is C code calling D code. This is 
important if your project is a mix of C and D code.

I did not anticipate or think of this when ImportC was conceived. It was a 
Eureka moment to discover it just kinda fell out of the implementation (adding 
10 lines of code to close the circle!).
May 15 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 15 May 2022 at 01:00:14 UTC, forkit wrote:

 The long, windy road 'could' have been anticipated.

 I certainly anticipated it when I read that PR.

 It'll be a long, windy road ahead to, for anyone having to 
 maintain projects that explicitly, actively, encourage you to 
 combine different languages.


Yes, there is no process, but by now it has become clear that D 
evolves by people starting to use incomplete features and quite a 
few are «given up on» and left incomplete like with most hobby 
projects. This is what happens when you start implementation 
before you have a design ready. This cannot be helped at this 
point as the culture is dominated by this experimental 
development mode.

To change this you have to shake up the whole process and the 
power stucture. And frankly it turns out that it is easier to 
just create a new language than to change this mindset. If you 
take the view that D is an ongoing experimental plaform you’ll 
feel better.

And that is perfectly fine, but it can be frustrating when people 
pretend it isn’t.
May 15 2022
parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 15 May 2022 at 07:39:21 UTC, Ola Fosheim Grøstad wrote:

 Yes, there is no process, but by now it has become clear that D 
 evolves by people starting to use incomplete features and quite 
 a few are «given up on» and left incomplete like with most 
 hobby projects. This is what happens when you start 
 implementation before you have a design ready.


Integrated C support with D has never been done before, and 
Walter never claimed supporting all preprocessor macros would 
work. ImportC was very useful even not long after it was first 
merged. I'm surprised at some of the negativity from people here.

Features are not given up on unless they're deprecated. The 
problem is manpower and getting through the dip process. The 
waterfall software development method is well known. I think your 
narrative is unfair and breeds negativity about D. The problems 
can often be solved, and when they can't it's because it's a 
problem with no known good solution or a trade off. But none of 
that is relevant to ImportC, which has obvious merit yet requires 
more work but clearly will pay its way.
May 15 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 15 May 2022 at 13:09:45 UTC, Nick Treleaven wrote:

 Walter never claimed supporting all preprocessor macros would 
 work.


One of the interesting potentials of importC is that all of them 
*could* work:

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


 ImportC was very useful even not long after it was first merged.


What did you use it for?
May 15 2022
next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Sunday, 15 May 2022 at 13:13:09 UTC, Adam D Ruppe wrote:

 On Sunday, 15 May 2022 at 13:09:45 UTC, Nick Treleaven wrote:

 Walter never claimed supporting all preprocessor macros would 
 work.


 One of the interesting potentials of importC is that all of 
 them *could* work:

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


 ImportC was very useful even not long after it was first 
 merged.


 What did you use it for?


I've imported some libraries directly into D. Not the headers, 
the whole library.
May 15 2022
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/15/22 08:34, Andrea Fontana wrote:

 On Sunday, 15 May 2022 at 13:13:09 UTC, Adam D Ruppe wrote:



 What did you use it for?


 I've imported some libraries directly into D. Not the headers, the whole
 library.



Same here.

I covered ImportC during a recent meetup. I literally did the following:


1) Copy/paste example code from libplot documentation into a D file.


2) Added the following line to my file:

   import plot;

Note: For that to work, I added the following line into my Makefile:

plot.i: plot.c Makefile
	gcc -I /usr/include -E $< > $ 

Once plot.i is generated by the external preprocessor, D could just 
import it. I must disclaim that plot.c was needed to do the following:

// This is needed because __restrict is not supported
#define __restrict restrict

// This is needed to skip the definition of the __REDIRECT macro because 
certain
// compatibility declarations of 'fscanf' and friends could not be 
parsed. (?)
#undef __GNUC__

// This is needed because plot.h uses FILE but fails to include stdio.h
#include "stdio.h"

// This is what our program needs
#include "plot.h"


3) I changed two places in the example C code:

3.i) Added .dup.ptr to the following literal because D's literals are 
not the same as C's literals:

   "PAGESIZE".dup.ptr

3.ii) I changed the following manifest constant to D:

// #define MAXORDER = 12;
enum MAXORDER = 12;


Summary: I (almost) copy/pasted C code into D and the entire code worked 
without even thinking about any binding.

Then I further experimenting with importing C files and D files between 
each other. It just worked.

I understand it is even simpler today because I think the issue with 
__restrict is gone and D can preprocess.

Ali
May 15 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 8:34 AM, Andrea Fontana wrote:

 I've imported some libraries directly into D. Not the headers, the whole
library.


Shazam! Tell us more!
May 15 2022
parent reply Andrea Fontana <nospam example.com> writes:
On Sunday, 15 May 2022 at 17:45:29 UTC, Walter Bright wrote:

 On 5/15/2022 8:34 AM, Andrea Fontana wrote:

 I've imported some libraries directly into D. Not the headers, 
 the whole library.


 Shazam! Tell us more!


I tested it  with some small libraries that do not need a 
makefile to compile (I'm too lazy to convert them).

For example this one 
https://github.com/nayuki/QR-Code-generator/tree/master/c works 
fine with the follow glue code:

```
#define __restrict restrict
#define __asm__ asm
#define __extension__
#define __inline inline
#define __signed__
#define _GNU_SOURCE

#include "qrcodegen.h"


static const int qrcode_VERSION_MIN = qrcodegen_VERSION_MIN;
static const int qrcode_VERSION_MAX = qrcodegen_VERSION_MAX;


size_t qrcode_BUFFER_LEN_FOR_VERSION(size_t n) { return 
qrcodegen_BUFFER_LEN_FOR_VERSION(n); }
size_t qrcode_BUFFER_LEN_MAX() { return 
qrcodegen_BUFFER_LEN_FOR_VERSION(qrcodegen_VERSION_MAX); }

#include "qrcodegen.c"
```

I use tcc to preprocess since it output a lot cleaner code.
Anyway I've imported many headers too, like libvlc, ffmpeg and so 
on...

Andrea
May 15 2022
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Nice, thank you!
May 15 2022
prev sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 15 May 2022 at 20:08:32 UTC, Andrea Fontana wrote:

 For example this one 
 https://github.com/nayuki/QR-Code-generator/tree/master/c works 
 fine with the follow glue code:


Hah, that is a library (one of the many) I ported to D.

https://github.com/adamdruppe/arsd/blob/master/qrcode.d

It took me about half an hour to do the full conversion by hand 
and put a basic D api and test on top of it.

Porting C to D is actually a pretty fast process...
May 15 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 6:13 AM, Adam D Ruppe wrote:

 On Sunday, 15 May 2022 at 13:09:45 UTC, Nick Treleaven wrote:

 Walter never claimed supporting all preprocessor macros would work.


 
 One of the interesting potentials of importC is that all of them *could* work:
 
 http://dpldocs.info/experimental-docs/mixinc.html


It's an interesting idea, but I'm a little unsure how it works. Does it propose 
running D code through the C preprocessor? That does not work, as the C 
preprocessor will fail with D tokens.
May 15 2022
parent reply Adam Ruppe <destructionator gmail.com> writes:
On Sunday, 15 May 2022 at 17:44:48 UTC, Walter Bright wrote:

 On 5/15/2022 6:13 AM, Adam D Ruppe wrote:

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


 It's an interesting idea, but I'm a little unsure how it works. 
 Does it propose running D code through the C preprocessor? That 
 does not work, as the C preprocessor will fail with D tokens.


Of course not. The whole point is to keep this separate: the D 
code is just normal D code. The embedded C code is just a string 
- just like with a D mixin.

But the mixinC construct, instead of passing that string through 
the D parser, passes it through the C preprocessor and C parser.

So it would be similar to a compile time function:

Node mixinC(string c_code) {
     c_code = c_preprocess(c_code);
     return parse(c_code);
}


It must form a complete ast node - just like a D mixin. So you 
can't

mixinC("#define START {");
mixinC("START");
// other code here
}


That won't work, since you can't make an ast node out of {. Same 
as how `mixin("{")` fails to compile.

But a complete node inside the string can be done, parsed as C, 
then have its node injected into D.

Max Haughton has a proof of concept PR already.


(my full proposal also includes exposing the preprocessor state 
as an immutable D object, so you can introspect the macros and 
define an order of operation through the return value. But even 
the basic thing with implied global state might be a step forward)
May 15 2022
next sibling parent Andrea Fontana <nospam example.org> writes:
On Sunday, 15 May 2022 at 20:34:25 UTC, Adam Ruppe wrote:


 Node mixinC(string c_code) {
     c_code = c_preprocess(c_code);
     return parse(c_code);
 }



My vote for mixin!C Vs mixin!D

Andrea
May 15 2022
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Sunday, 15 May 2022 at 20:34:25 UTC, Adam Ruppe wrote:

 On Sunday, 15 May 2022 at 17:44:48 UTC, Walter Bright wrote:

 On 5/15/2022 6:13 AM, Adam D Ruppe wrote:

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


 It's an interesting idea, but I'm a little unsure how it 
 works. Does it propose running D code through the C 
 preprocessor? That does not work, as the C preprocessor will 
 fail with D tokens.


 Of course not. The whole point is to keep this separate: the D 
 code is just normal D code. The embedded C code is just a 
 string - just like with a D mixin.

 But the mixinC construct, instead of passing that string 
 through the D parser, passes it through the C preprocessor and 
 C parser.

 So it would be similar to a compile time function:

 Node mixinC(string c_code) {
     c_code = c_preprocess(c_code);
     return parse(c_code);
 }


 It must form a complete ast node - just like a D mixin. So you 
 can't

 mixinC("#define START {");
 mixinC("START");
 // other code here
 }


 That won't work, since you can't make an ast node out of {. 
 Same as how `mixin("{")` fails to compile.

 But a complete node inside the string can be done, parsed as C, 
 then have its node injected into D.

 Max Haughton has a proof of concept PR already.


 (my full proposal also includes exposing the preprocessor state 
 as an immutable D object, so you can introspect the macros and 
 define an order of operation through the return value. But even 
 the basic thing with implied global state might be a step 
 forward)


So far it looks like mixinC is semantically functional, the only 
slight hiccup with the scheme is that currently you can't have a 
C struct initializer as the input to one so you may need to use a 
mixinC declaration when in C an "expression" on the RHS would 
have sufficed.

A large subset of macros will be simple enough to turn into D 
ASTs directly. If it can't be then the identifier could he 
recognized and an error message shown to the user. I say this 
directly because so far ImportC ignores things it does not 
understand which will have to stop at some point.
May 15 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 2:28 PM, max haughton wrote:

 I say this directly because so far ImportC ignores things it does 
 not understand which will have to stop at some point.


I'm not aware of any case where ImportC silently ignores things it does not 
understand.
May 15 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Thank you for the explanation. It's a bit clearer to me, now.

But what is missing is a compelling use case for it?
May 15 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 16 May 2022 at 01:05:33 UTC, Walter Bright wrote:

 But what is missing is a compelling use case for it?


It is the only way I've seen that would let you ACTUALLY use full 
C APIs.

Take a look at some of these macros a quick grep through my 
system include directory:

pqStubs.h:#define PQcmdTuples (pqStubs->PQcmdTuplesPtr)

curses.h:#define getcurx(win)           (NCURSES_OK_ADDR(win) ? 
(win)->_curx : ERR)




You can convert many of these from C to D with some string 
manipulations. replace("->", ".") and wrap it in a template 
function and you will go a long way. (This is what dstep does, 
and it actually works about 95% of the time.)

But what about this one?

/* Evaluate to actual length of the `sockaddr_un' structure.  */

0)->sun_path)        \
                       + strlen ((ptr)->sun_path))



The casts get more and more complicated. To convert this starts 
to require a C parser to convert that code back to D on an ast 
level... and the C parser is exactly what ImportC is, and D's 
facility for parsing a string and converting it to a D ast is 
what `mixin` does.


So combining them thus becomes MixinC.



There's one in this directory I saw before but I don't remember 
where it is, that has something like

#define item child.item

And you'd use it in C like:

yourstruct.item


So it is basically an `alias this` style forwarder done as a C 
macro. This is extremely difficult to express in any kind of D 
conversion, and dpp's approach is very likely to mangle code 
since it lacks semantic awareness.

MixinC bypasses this - it lets it continue be expressed in C, but 
it is limited to a single string literal, so it doesn't allow the 
preprocess to destroy unrelated D code. It is the exact same 
logic as `mixin` being hygienic as it is, just using C strings 
instead of D strings.

In some of these cases, you can express the macro in D directly 
as:

auto SUN_LEN(T)(T ptr) {
  return mixinC(`((size_t) (((struct sockaddr_un *) 0)->sun_path)
                       + strlen ((ptr)->sun_path))`);
}



Or if this isn't done, user code can still:

`size_t s = mixinC("SUN_LEN(my_ptr)");`


Which is syntatically slightly verbose, but that's a cost worth 
paying to maintain the syntax hygiene.... and it works with 
*arbitrary macros* (yes, even ones like `#define BEGIN {`, 
assuming you put the BEGIN and END pieces in the same string, to 
form a valid AST node).


The C preprocessor is a string macro system. D's mixin is a 
string to code system. They can work well together!




If your goal is for system headers to Just Work, and it doesn't 
include some of these macros that are part of the defined API, it 
is going to fall short. The point of the MixinC concept is to 
bridge that gap, giving a solution to the preprocessor macro 
problem.

And besides, notice that, if done right, this can also:

* Enable CTFE to generate C code as well as D code. (You likely 
could write a C preprocessor in D, run it in CTFE, and mixin the 
result!)

* Enable deeper introspection into a complete C api, including 
defined macros and version symbols, allowing custom expressions 
of those to be used in D.



There's still some things ImportC with MixinC would need design 
work on - the `import` namespace is still a mess (I'll write a 
blog about this at some point too, it is past bed time right now) 
- but making all this work would really feel like actually 
unlocking the power of tearing down the barriers between C and D.

ImportC as it is now is just "meh, it'd save me 15 minutes every 
6 months".

ImportC as it could be might unlock a whole new world of C/D 
metaprogramming.

Mr. Bright, TEAR DOWN THIS WALL
May 15 2022
next sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:

 ...
 ....
 ImportC as it could be might unlock a whole new world of C/D 
 metaprogramming.

 Mr. Bright, TEAR DOWN THIS WALL


You do understand what lives on the other side of this wall, 
don't you?

C!
May 15 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 16 May 2022 at 01:54:58 UTC, forkit wrote:

 On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:

 ...
 ....
 ImportC as it could be might unlock a whole new world of C/D 
 metaprogramming.

 Mr. Bright, TEAR DOWN THIS WALL


 You do understand what lives on the other side of this wall, 
 don't you?

 C!


C is a bad programming language but equally it's the lingua 
franca of almost everything useful so it's not really up to us.

Recently when I've been fiddling around with the lowing of IR -> 
LLVM in SDC, the calls to the C API were written roughly 9 years 
ago and they are all still passing the tests. If you want that 
kind of stability you have to be able to talk C. I note that the 
bindings also still work just fine but that's for a different 
discussion...

Wanna talk to postgres? You're most likely going to need a C 
library, otherwise you have nothing to ship.
May 15 2022
parent reply forkit <forkit gmail.com> writes:
On Monday, 16 May 2022 at 02:17:50 UTC, max haughton wrote:

 C is a bad programming language but equally it's the lingua 
 franca of almost everything useful so it's not really up to us.


It's the 'lingua franca' because everyone treats it as such ;-)

It's also a frankish language that has contributed to more 
invalid memory accesses, invalid type casts, memory leaks, data 
races, deadlocks, etc... than any other language, ever to exist.

But hey, whatever,... , let's just import more of it

:-(
May 15 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 16/05/2022 2:53 PM, forkit wrote:

 On Monday, 16 May 2022 at 02:17:50 UTC, max haughton wrote:

 C is a bad programming language but equally it's the lingua franca of 
 almost everything useful so it's not really up to us.


 
 It's the 'lingua franca' because everyone treats it as such ;-)
 
 It's also a frankish language that has contributed to more invalid 
 memory accesses, invalid type casts, memory leaks, data races, 
 deadlocks, etc... than any other language, ever to exist.
 
 But hey, whatever,... , let's just import more of it
 
 :-(


Max is correct. It doesn't matter what we want. It is the language that 
other languages communicate through primarily.

If you want to do anything on Windows you must work with C and COM. So 
we must support both of them as best as we can. You can't realistically 
talk to the kernel to replicate this behavior.

If we want D running on proprietary systems that have license 
restrictions with distribution, we must have a way to create bindings to 
the C system headers (this is an issue for GDC).
May 15 2022
prev sibling parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 16 May 2022 at 02:53:03 UTC, forkit wrote:

 On Monday, 16 May 2022 at 02:17:50 UTC, max haughton wrote:

 C is a bad programming language but equally it's the lingua 
 franca of almost everything useful so it's not really up to us.


 It's the 'lingua franca' because everyone treats it as such ;-)

 It's also a frankish language that has contributed to more 
 invalid memory accesses, invalid type casts, memory leaks, data 
 races, deadlocks, etc... than any other language, ever to exist.

 But hey, whatever,... , let's just import more of it

 :-(


Unless you have a magic wand or a time machine I don't see how 
this line of argument has any relevance to the practice of 
writing software that actually does anything other than making 
the machine get hot.

One thing I'd also like to note is that once the C has been 
turned into the D AST you actually can almost get it to emit D 
code that represents the C
May 15 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 8:59 PM, max haughton wrote:

 One thing I'd also like to note is that once the C has been turned into the D 
 AST you actually can almost get it to emit D code that represents the C


"almost" is the operative word, here :-/

One of the motivations for ImportC (as opposed to C=>D translations that htod, 
dstep, and dpp do) is that the semantics can be an exact match to C.
May 15 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 16 May 2022 at 05:11:42 UTC, Walter Bright wrote:

 On 5/15/2022 8:59 PM, max haughton wrote:

 One thing I'd also like to note is that once the C has been 
 turned into the D AST you actually can almost get it to emit D 
 code that represents the C


 "almost" is the operative word, here :-/

 One of the motivations for ImportC (as opposed to C=>D 
 translations that htod, dstep, and dpp do) is that the 
 semantics can be an exact match to C.


The semantics will be an exact match because I'm talking about 
merely making the dmd AST dumping feature better versus a new 
tool. It basically already works it's just that you have to make 
it not emit `import object` and also fix a bug in the dmd parser 
because extern(C) doesn't work inside a function parameter or 
something to that effect.
May 15 2022
parent max haughton <maxhaton gmail.com> writes:
On Monday, 16 May 2022 at 05:13:52 UTC, max haughton wrote:

 On Monday, 16 May 2022 at 05:11:42 UTC, Walter Bright wrote:

 On 5/15/2022 8:59 PM, max haughton wrote:

 [...]


 "almost" is the operative word, here :-/

 One of the motivations for ImportC (as opposed to C=>D 
 translations that htod, dstep, and dpp do) is that the 
 semantics can be an exact match to C.


 The semantics will be an exact match because I'm talking about 
 merely making the dmd AST dumping feature better versus a new 
 tool. It basically already works it's just that you have to 
 make it not emit `import object` and also fix a bug in the dmd 
 parser because extern(C) doesn't work inside a function 
 parameter or something to that effect.


Further note that I don't really care about the bodies of 
functions, so 99% of the usefulness is 30% of the problem.
May 15 2022
prev sibling parent forkit <forkit gmail.com> writes:
On Monday, 16 May 2022 at 03:59:30 UTC, max haughton wrote:

 Unless you have a magic wand or a time machine I don't see how 
 this line of argument has any relevance to the practice of 
 writing software that actually does anything other than making 
 the machine get hot.


We're talking about the difference between D communicating with 
the 'outside' world (which as we *both* argue, is required), and 
D going 'all out' to bring the outside world in (which is not 
necessarily something I'm on board with).

D had no problem interacting with C before ImportC. ImportC does 
not assist here.

You can actually write C code in D anyway. ImportC does not 
assist here either.

We are no longer talking about a lingua franca to communicate 
with the outside world. We're talking about ensuring that the 
tyrannny of C becomes a bigger part of our world. That's the 
promise of ImportC.


 One thing I'd also like to note is that once the C has been 
 turned into the D AST you actually can almost get it to emit D 
 code that represents the C


This I'd be on board with. 100%.
May 15 2022
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 6:41 PM, Adam D Ruppe wrote:

 On Monday, 16 May 2022 at 01:05:33 UTC, Walter Bright wrote:

 But what is missing is a compelling use case for it?


 
 It is the only way I've seen that would let you ACTUALLY use full C APIs.


This is replacing C #define's with D constructions, right?

You're right, ImportC does not do that at the moment. However, it's always been 
the plan for it to gather up all the #define's, and replace the ones that can
be 
replaced with D constructs, and ignore the rest.

I'm not going to pretend this can ever be a complete 100% solution, after all:

     #define BEGIN {
     #define END }

What can one do with that? Phooey.

I've talked with Atila about how dpp handles it. dpp looks for general
patterns, 
and replaces those with generic D constructs. Atila (always the pragmatist)
also 
programmed in specific replacements for specific #defines that appear in
popular 
.h files. This is indeed an endless game of whack-a-mole, but it works, and it 
gets the job done.

I intend to leverage Atila's work for ImportC to do the same thing.

(It also may be possible to make these specific patterns something that users 
can contribute to, so they don't have to wait for the compiler team.)

But I still don't understand - why mixin this stuff? Why would someone want to 
type C code into a D source file?
May 15 2022
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
```d
void main() {
     import std.stdio;
     writeln("Starting application");

     mixinc(qc{
         #include <stdio.h>
         #include <string.h>
         #include <lua.h>
         #include <lauxlib.h>
         #include <lualib.h>

           char buff[256];
           int error;
           lua_State *L = lua_open();   /* opens Lua */
           luaopen_base(L);             /* opens the basic library */
           luaopen_table(L);            /* opens the table library */
           luaopen_io(L);               /* opens the I/O library */
           luaopen_string(L);           /* opens the string lib. */
           luaopen_math(L);             /* opens the math lib. */

           while (fgets(buff, sizeof(buff), stdin) != NULL) {
             error = luaL_loadbuffer(L, buff, strlen(buff), "line") ||
                     lua_pcall(L, 0, 0, 0);
             if (error) {
               fprintf(stderr, "%s", lua_tostring(L, -1));
               lua_pop(L, 1);  /* pop error message from the stack */
             }
           }

           lua_close(L);
     });

     writeln("Program end");
}
```

Copied the function body from[0].

Now imagine some awful macros that exist. It allows you to bridge C into 
D without creating new or modifying any C files.

This is the ultimate tool for porting C to D.

[0] https://www.lua.org/pil/24.1.html
May 15 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Interesting. I note that this is inserting C expressions and statements into D 
functions. ImportC works at the declaration level - i.e. inserting C symbols. I 
expect there may be impedance mismatch problems by putting it at a lower level. 
In fact I'm certain that a redo of how the C semantics are handled in the 
compiler would be necessary.
May 15 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 16 May 2022 at 05:08:58 UTC, Walter Bright wrote:

 Interesting. I note that this is inserting C expressions and 
 statements into D functions. ImportC works at the declaration 
 level - i.e. inserting C symbols. I expect there may be 
 impedance mismatch problems by putting it at a lower level. In 
 fact I'm certain that a redo of how the C semantics are handled 
 in the compiler would be necessary.


The PoC for mixinC (the syntax is actually mixin[C] because it 
was easier to parse) that I did doesn't blow up (note: this does 
not mean it works) many things I tried.

As long as the semantic analysis can happen in a new Scope (a dmd 
one not a lexical one) then the normal semantic routines should 
work and it'll be the same as any other mixin (I.e. mixin is not 
free of bugs).
May 15 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 16/05/2022 5:16 PM, max haughton wrote:

 As long as the semantic analysis can happen in a new Scope (a dmd one 
 not a lexical one) then the normal semantic routines should work and 
 it'll be the same as any other mixin (I.e. mixin is not free of bugs).


Indeed, we already have scope awareness of C vs D. As long as we can mix 
them (within each other) than shouldn't need things to be redone.

It shouldn't be any different than:

void main() {
	writeln;

	{
		... c ...
	}

	writeln;
}
May 15 2022
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 16 May 2022 at 03:12:47 UTC, Walter Bright wrote:

 But I still don't understand - why mixin this stuff? Why would 
 someone want to type C code into a D source file?


dpp and dstep are not always able to divine the meaning of a 
given macro, so having an escape hatch is either necessary or the 
most direct way of doing certain things.

If you use them you can see that they're just looking for 
relatively simple patterns, not magic. You can approximate magic 
a little by looking at how a macro is used within a source file 
(if you're lucky), but extracting this info programmatically 
would use a lot of niche infrastructure and thinking that is 
probably beyond reachh.

ImportC does not (currently) emit a D equivalent to a header 
file, which means that documenting what it actually does for some 
non-trivial preprocessor metaprogramming uglyvomityuck is going 
to be irritating.

You have a C API, dstep might turn that into a template, which 
might be initially confusing but you can just grep (or use an 
IDE) for the symbol (or lack thereof if it couldn't do it). With 
ImportC this is now much murkier for obvious reasons (although 
I'll note that adding a palatable header-output mode is something 
I've played around with and honestly wouldn't be particularly 
hard as long as we kept a little bit more info around in the 
compiler).

So you're in a hurry and you can't seem to get a macro working? 
mixinC the bit you need. It's either that or doing it in your 
head anyway.
May 15 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 9:39 PM, max haughton wrote:

 So you're in a hurry and you can't seem to get a macro working? mixinC the bit 
 you need. It's either that or doing it in your head anyway.


Ok, I see what you're talking about.

But what I'd do is put that use of the macro in a .c file and import it.
May 15 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 16 May 2022 at 05:06:02 UTC, Walter Bright wrote:

 But what I'd do is put that use of the macro in a .c file and 
 import it.


This is impractical for the small expressions many of these 
macros are designed for. You might as well just write C at that 
point.
May 16 2022
parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 16 May 2022 at 13:20:32 UTC, Adam D Ruppe wrote:

 On Monday, 16 May 2022 at 05:06:02 UTC, Walter Bright wrote:

 But what I'd do is put that use of the macro in a .c file and 
 import it.


 This is impractical for the small expressions many of these 
 macros are designed for. You might as well just write C at that 
 point.


I feel like Walter asking about use case could also consider his 
words earlier in the thread:


 I've done many projects that were universally derided as "who 
 needs that" until they got their hands on it. :-)
 
 I've also done many projects that everybody wanted, until I 
 delivered it. (dscript)
 
 It's kinda hard to tell these things in advance, especially if 
 they involve a change in the way people are used to doing 
 things."
May 16 2022
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 16 May 2022 at 03:12:47 UTC, Walter Bright wrote:

 I'm not going to pretend this can ever be a complete 100% 
 solution, after all:

     #define BEGIN {
     #define END }

 What can one do with that? Phooey.


Just do the right thing. Build macro expansion into the lexer and 
tag tokens from macros. Then sort it out in the parser an 
remaining ambiguities in semantic analysis.


 I've talked with Atila about how dpp handles it. dpp looks for 
 general patterns, and replaces those with generic D


Sounds like a hack. Think instead in terms of C grammar 
productions and how they match with D.


 But I still don't understand - why mixin this stuff? Why would 
 someone want to type C code into a D source file?


The problem isnt why, but that it will make code less readable 
and only be understood by the inner hardcore.

You really need to set up a list of requirements for what is 
needed in terms of usability for regular D users otherwise 
forkit’s concerns will materialize...
May 15 2022
prev sibling next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 16 May 2022 at 03:12:47 UTC, Walter Bright wrote:

 This is replacing C #define's with D constructions, right?


No. It is about not having to. Instead of converting to D (and 
being forced to fail in certain cases), you just mixinC.


 I'm not going to pretend this can ever be a complete 100% 
 solution, after all:

    #define BEGIN {
    #define END }

 What can one do with that? Phooey.


This is an example I showed *can actually work* in the message 
you're quoting. Of course, they'd have to be paired in the mixed 
in block, but it would work once you get a complete ast node 
assembled.

Very similar to D's

enum string BEGIN = "{";
enum string END = "}";
mixin(BEGIN ~ "stuff" ~ END);


mixin(BEGIN) obviously not going to work, but if you concat the 
strings to form a complete statement, you have something that can 
be used.

The C preprocessor is very similar to string replacement and 
concatenation.


 But I still don't understand - why mixin this stuff?
 Why would someone want to type C code into a D source file?


Why would someone want to use inline assembler? Why would someone 
want to use CTFE on C? Why would someone want to type __import in 
a C file?
May 16 2022
prev sibling parent Adrian Matoga <dlang.spam matoga.info> writes:
On Monday, 16 May 2022 at 03:12:47 UTC, Walter Bright wrote:

 On 5/15/2022 6:41 PM, Adam D Ruppe wrote:

 On Monday, 16 May 2022 at 01:05:33 UTC, Walter Bright wrote:

 But what is missing is a compelling use case for it?


 
 It is the only way I've seen that would let you ACTUALLY use 
 full C APIs.


 This is replacing C #define's with D constructions, right?

 You're right, ImportC does not do that at the moment. However, 
 it's always been the plan for it to gather up all the 
 #define's, and replace the ones that can be replaced with D 
 constructs, and ignore the rest.


That will be very handy of course and some users may heavily 
demand it, but at the before-ImportC times, when I dreamt of 
having a C frontend integrated with D compiler, I assumed it'd be 
good enough if I could just write a one line wrapper function in 
the C file to call the ugly macro, for anything that's not 
auto-convertible to plain enum constant.
May 18 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:

 There's still some things ImportC with MixinC would need design 
 work on - the `import` namespace is still a mess (I'll write a 
 blog about this at some point too, it is past bed time right 
 now)


Here's the post about this:

http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html#importc-and-module-namespaces
May 16 2022
parent reply Dave P. <dave287091 gmail.com> writes:
On Monday, 16 May 2022 at 17:31:26 UTC, Adam D Ruppe wrote:

 On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:

 There's still some things ImportC with MixinC would need 
 design work on - the `import` namespace is still a mess (I'll 
 write a blog about this at some point too, it is past bed time 
 right now)


 Here's the post about this:

 http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html#importc-and-module-namespaces


I reported this as a bug back in January: 
https://issues.dlang.org/show_bug.cgi?id=22674
May 16 2022
parent Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 16 May 2022 at 17:43:14 UTC, Dave P. wrote:

 I reported this as a bug back in January: 
 https://issues.dlang.org/show_bug.cgi?id=22674


Nice. Yeah, I would have been surprised if I was the first person 
to notice it, since it is frankly pretty obvious (and happens 
even with hand-written things from time to time, and was a big 
issue with dpp, so not even new).

I didn't see that bug though maybe I'll edit the post to put in a 
link. Walter going "WONTFIX" is pretty much expected though, 
sadly.
May 16 2022
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 15 May 2022 at 13:09:45 UTC, Nick Treleaven wrote:

 Integrated C support with D has never been done before, and 
 Walter never claimed supporting all preprocessor macros would 
 work.


There is no process behind this, so what exactly are the 
requirements from "non-hardcore" users?

All I can say that 90% is probably worse than nothing from the 
perspective of someone externally evaluating the language.


 But none of that is relevant to ImportC, which has obvious 
 merit yet requires more work but clearly will pay its way.


Yes, it has obvious merits, but if people start using it before 
it is a complete solution, then it will never reach a state of 
completion. It will become another «not quite there, but 
sufficient for the fan-base».

To put this is perspective: I actually find the differences 
between C++ and C rather problematic. And those are minimal.
May 15 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 6:09 AM, Nick Treleaven wrote:

 Integrated C support with D has never been done before, and Walter never
claimed 
 supporting all preprocessor macros would work.


In fact I specifically said that the preprocessor macros would never fully
work. 
Even though one could feed D source code through the C preprocessor, it will 
fail to preprocess, as D does not wholly consist of preprocessor tokens. (The 
ancient K+R preprocessor would, but standard C wedded the preprocessor
semantics 
to C.)



 ImportC was very useful even not 
 long after it was first merged. I'm surprised at some of the negativity from 
 people here.


I'm not. I've done many projects that were universally derided as "who needs 
that" until they got their hands on it. :-)

I've also done many projects that everybody wanted, until I delivered it.
(dscript)

It's kinda hard to tell these things in advance, especially if they involve a 
change in the way people are used to doing things.



 Features are not given up on unless they're deprecated. The problem is
manpower 
 and getting through the dip process. The waterfall software development method 
 is well known. I think your narrative is unfair and breeds negativity about D. 
 The problems can often be solved, and when they can't it's because it's a 
 problem with no known good solution or a trade off. But none of that is
relevant 
 to ImportC, which has obvious merit yet requires more work but clearly will
pay 
 its way.


And now with:

   https://github.com/dlang/dmd/pull/14128

you can pass preprocessor commands to cpp when using ImportC. Getting better 
every day!
May 15 2022
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/14/22 18:00, forkit wrote:

 On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 ...

 It's been a longer and windy-er road than I'd anticipated, but isn't
 that the way all software projects work?
 ...


 Well...I'm not aware of any software projects where someone wakes up one
 morning, with a thought bubble, and then decides to submit a PR, marked
 as 'Trivial', that adds a C compiler insider an already existing
 compiler for a different language.


I am fortunate to be a part of a community where such inventions pop up 
from time to time.


 https://github.com/dlang/dmd/pull/12507/

 The long, windy road 'could' have been anticipated.


I did not read that threat but I can't see any comment by 'forkit' 
there. Could you not make yourself clear there to find a shortcut for 
the long, windy road? In any case I am missing your point. Are you 
wishing anticipation for the future? Or do you think we should rip this 
feature out completely? (I am asking those in the light of general 
negative sentiments.)


 I certainly anticipated it when I read that PR.


That sounds like "I told you so," which doesn't help. Surely, you don't 
mean others did anticipate but still put "Trivial" anyway?


 It'll be a long, windy road ahead to, for anyone having to maintain
 projects that explicitly, actively, encourage you to combine different
 languages.


Thanks for the heads up. I hope your attitude does not stop ideas for 
future invention.

More on topic, I am one of those who thinks ImportC is amazing and will 
be very useful. There is potential in it. The discovery of "modules for 
C" is unbelievable to me. It came only because one inventor thought an 
otherwise unrelated idea was worth pursuing.

Ali
May 15 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 15 May 2022 at 14:57:36 UTC, Ali Çehreli wrote:

 More on topic, I am one of those who thinks ImportC is amazing 
 and will be very useful. There is potential in it.


Yes, there is potential, but can we agree that encouraging people 
to use it (for other things than testing) is not a good idea 
until the feature is complete? You risk killing off the potential 
by locking it down to a premature design.


 The discovery of "modules for C" is unbelievable to me. It came 
 only because one inventor thought an otherwise unrelated idea 
 was worth pursuing.


What is it? I've seen it mentioned, but I don't understand what 
it is yet.  In C you typically use textual prefixes to establish 
namespaces, so how can you deal with that?
May 15 2022
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 15 May 2022 at 15:44:42 UTC, Ola Fosheim Grøstad wrote:

 On Sunday, 15 May 2022 at 14:57:36 UTC, Ali Çehreli wrote:


 The discovery of "modules for C" is unbelievable to me. It 
 came only because one inventor thought an otherwise unrelated 
 idea was worth pursuing.


 What is it? I've seen it mentioned, but I don't understand what 
 it is yet.  In C you typically use textual prefixes to 
 establish namespaces, so how can you deal with that?


https://dlang.org/changelog/2.099.0.html#__import
May 15 2022
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/15/22 08:44, Ola Fosheim Grøstad wrote:

 On Sunday, 15 May 2022 at 14:57:36 UTC, Ali Çehreli wrote:

 More on topic, I am one of those who thinks ImportC is amazing and
 will be very useful. There is potential in it.


 Yes, there is potential, but can we agree that encouraging people to use
 it (for other things than testing) is not a good idea until the feature
 is complete? You risk killing off the potential by locking it down to a
 premature design.


Agreed. This is a documentation bug: The following page should say "This 
feature is under construction.":

   https://dlang.org/spec/importc.html

At the moment it says "This document is under construction."


 The discovery of "modules for C" is unbelievable to me. It came only
 because one inventor thought an otherwise unrelated idea was worth
 pursuing.


 What is it? I've seen it mentioned, but I don't understand what it is
 yet.


Walter explained the implementation of ImportC at this meetup:

   https://nwcpp.org/April-2022.html

He started from the point of view of the compiler writer, explaining 
symbol tables. Once a C file is parsed, it gets converted into a 
language-agnostic module. Once both D and C coexist as modules, they can 
interact as modules do. As a result, the following surprises emerge:

- C can import D
- C can call D struct constructors, destructors, .init, etc.
- C can import C (no more header files)
- Template instantiation from C
- Function overloads for C
- Introspection for C
- etc. (I can't think of right now what else may be hidden in there.)

The only requirement is to compile the C module with dmd.

I covered ImportC in a recent meetup but only Nicholas Wilson showed up 
and he and I had fun experiments with this feature:

   https://forum.dlang.org/thread/t0r1qn$2fnu$1 digitalmars.com

Our meeting was from the point of view of the user.

Ali
May 15 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
On Sunday, 15 May 2022 at 14:57:36 UTC, Ali Çehreli wrote:

 ...
 That sounds like "I told you so," which doesn't help. Surely, 
 you don't mean others did anticipate but still put "Trivial" 
 anyway?


No. Others did anticipate it. That's why the Trivial tag was 
removed ;-)

But the PR was submitted with a Trivial tag, suggesting the 
person submitting that PR did not anticipate the long, windy road 
ahead (which others did).

Anyway, the point has been made. Can we move on?
May 15 2022
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/15/22 16:50, forkit wrote:


 Can we move on?


Yes! :)

Ali
May 15 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 4:50 PM, forkit wrote:

 But the PR was submitted with a Trivial tag, suggesting the person submitting 
 that PR did not anticipate the long, windy road ahead (which others did).


Jeez, it was joke!

    -- Captain Obvious
May 15 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/14/2022 6:00 PM, forkit wrote:

 It'll be a long, windy road ahead to, for anyone having to maintain projects 
 that explicitly, actively, encourage you to combine different languages.


I understand as well as anyone that languages evolve and need maintenance. But
I 
am also very aware that despite C's popularity, it evolves very very slowly. So 
this is a fairly low risk for us.
May 15 2022
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 As https://github.com/dlang/dmd/pull/14121 has been merged, the 
 following #ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

 It's been a longer and windy-er road than I'd anticipated, but 
 isn't that the way all software projects work?


Amazing. Thanks and congratulations to everyone who worked on 
this feature.

I'm looking forward to the future when we can stop worrying and 
deprecate the entirety of https://github.com/D-Programming-Deimos.
May 15 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2022 6:16 AM, Vladimir Panteleev wrote:

 I'm looking forward to the future when we can stop worrying and deprecate the 
 entirety of https://github.com/D-Programming-Deimos.


So am I. I'll be happy to bury it.

BTW, if anyone wants to start trying ImportC with Diemos projects, and
reporting 
to bugzilla any issues encountered, we can move along even faster!
May 15 2022
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 As https://github.com/dlang/dmd/pull/14121 has been merged, the 
 following #ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

 It's been a longer and windy-er road than I'd anticipated, but 
 isn't that the way all software projects work?


Go ImportC! Great news, and great feature.
May 15 2022
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 As https://github.com/dlang/dmd/pull/14121 has been merged, the 
 following #ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

 It's been a longer and windy-er road than I'd anticipated, but 
 isn't that the way all software projects work?

 Next up:

 1. passing dmd command line arguments to the preprocessor

 2. capturing the #define macro dump from the preprocessor, so 
 it can be mined for macros that can be translated to D symbols 
 (anticipating leveraging Atila's great dpp work on this)


I don't understand where this is going at all. At first, I 
thought that this was able being able to import c (as the name 
would suggest), which seems super useful, but now it seems to be 
evolving into a full blow C compiler and I have no idea why I 
would want that. I already have several on my machine, and they 
are extremely high quality.
May 16 2022
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 16 May 2022 at 09:52:21 UTC, deadalnix wrote:

 On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 As https://github.com/dlang/dmd/pull/14121 has been merged, 
 the following #ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

 It's been a longer and windy-er road than I'd anticipated, but 
 isn't that the way all software projects work?

 Next up:

 1. passing dmd command line arguments to the preprocessor

 2. capturing the #define macro dump from the preprocessor, so 
 it can be mined for macros that can be translated to D symbols 
 (anticipating leveraging Atila's great dpp work on this)


 I don't understand where this is going at all. At first, I 
 thought that this was able being able to import c (as the name 
 would suggest), which seems super useful, but now it seems to 
 be evolving into a full blow C compiler and I have no idea why 
 I would want that. I already have several on my machine, and 
 they are extremely high quality.


importRust and importGo are coming in the next release.

No need for multiple compilers anymore, all languages will exist 
in a single compiler, DMD.
May 16 2022
parent reply zjh <fqbqrr 163.com> writes:
On Monday, 16 May 2022 at 10:27:45 UTC, bauss wrote:


 importRust and importGo are coming in the next release.


That's it. Theirs are mines.
May 16 2022
parent reply zjh <fqbqrr 163.com> writes:
On Monday, 16 May 2022 at 10:41:01 UTC, zjh wrote:


 importRust and importGo are coming in the next release.




`importC++` is the most important!
May 16 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 16 May 2022 at 10:42:35 UTC, zjh wrote:

 On Monday, 16 May 2022 at 10:41:01 UTC, zjh wrote:



 `importC++` is the most important!


`importC++` may be impossible.
But `ImportRust` is definitely worth it!
May 16 2022
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Monday, 16 May 2022 at 10:42:35 UTC, zjh wrote:

 On Monday, 16 May 2022 at 10:41:01 UTC, zjh wrote:


 importRust and importGo are coming in the next release.




 `importC++` is the most important!


importC++ won't happen because that's just going to be D as D is 
often seen as a better C++ for whatever reason.

There's no need to have importC++ for philosophical D reasons.
May 16 2022
parent zjh <fqbqrr 163.com> writes:
On Monday, 16 May 2022 at 11:48:47 UTC, bauss wrote:


 There's no need to have importC++ for philosophical D reasons.


If we can make use of the ecology of `C++`, it's really good.
May 16 2022
prev sibling parent reply Adrian Matoga <dlang.spam matoga.info> writes:
On Monday, 16 May 2022 at 10:42:35 UTC, zjh wrote:

 On Monday, 16 May 2022 at 10:41:01 UTC, zjh wrote:


 importRust and importGo are coming in the next release.




 `importC++` is the most important!


It's not something that people haven't tried before: 
https://github.com/Syniurge/Calypso
May 18 2022
parent zjh <fqbqrr 163.com> writes:
On Wednesday, 18 May 2022 at 20:42:47 UTC, Adrian Matoga wrote:


 https://github.com/Syniurge/Calypso



No longer maintained projects is not good projects.
May 18 2022
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 16 May 2022 at 09:52:21 UTC, deadalnix wrote:

 I don't understand where this is going at all. At first, I 
 thought that this was able being able to import c (as the name 
 would suggest), which seems super useful, but now it seems to 
 be evolving into a full blow C compiler and I have no idea why 
 I would want that. I already have several on my machine, and 
 they are extremely high quality.


Yes, but you need to be able to compile C in order to expand 
C-macros in D code.

It isn't all that difficult (but tedious to implement).

Possible implementation:

1. Tokenize the whole sourcefile before parsing, and mix 
tokenization with macro expansion. In this process you tag all 
non-macro tokens as D, tag all macro-originating tokens as C and 
all macro-parameter tokens as both (unless explicitly tagged as 
either C or D).

2. Study all the productions for C and D so that you know how to 
deal with lookahead.

3. Use a backtracking parser (e.g. Earley parser, but that might 
be overkill) and build the AST.

4. Resolve ambiguous symbols in post parsing, guided by weather 
the originating token was tagget as D, C or both.

This way you get to mix C and D, but also prevent people from 
writing macros containing D code.

As long as all C code can be expressed in the D AST you're good.
May 16 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2022 2:52 AM, deadalnix wrote:

 I don't understand where this is going at all. At first, I thought that this
was 
 able being able to import c (as the name would suggest), which seems super 
 useful, but now it seems to be evolving into a full blow C compiler and I have 
 no idea why I would want that. I already have several on my machine, and they 
 are extremely high quality.


People can and do put the full C language into .h files (for example, functions 
that are expected to be inlined).
May 16 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 17 May 2022 at 05:11:01 UTC, Walter Bright wrote:

 On 5/16/2022 2:52 AM, deadalnix wrote:

 I don't understand where this is going at all. At first, I 
 thought that this was able being able to import c (as the name 
 would suggest), which seems super useful, but now it seems to 
 be evolving into a full blow C compiler and I have no idea why 
 I would want that. I already have several on my machine, and 
 they are extremely high quality.


 People can and do put the full C language into .h files (for 
 example, functions that are expected to be inlined).


Yeah, header-only libraries are very popular among users, since 
it helps keep binary sizes under control, so authors shove as 
much of the functionality as possible into the header files
May 17 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 17 May 2022 at 07:15:52 UTC, Tejas wrote:

 On Tuesday, 17 May 2022 at 05:11:01 UTC, Walter Bright wrote:

 On 5/16/2022 2:52 AM, deadalnix wrote:

 I don't understand where this is going at all. At first, I 
 thought that this was able being able to import c (as the 
 name would suggest), which seems super useful, but now it 
 seems to be evolving into a full blow C compiler and I have 
 no idea why I would want that. I already have several on my 
 machine, and they are extremely high quality.


 People can and do put the full C language into .h files (for 
 example, functions that are expected to be inlined).


 Yeah, header-only libraries are very popular among users, since 
 it helps keep binary sizes under control, so authors shove as 
 much of the functionality as possible into the header files


Yeah, because linkers and LTO are yet to be invented.
May 17 2022
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 As https://github.com/dlang/dmd/pull/14121 has been merged, the 
 following #ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

 [snip]


Sorry if this is a dumb question, but when you refer to something 
as a "ImportC" program, what precisely do you mean? It's a D 
program that requires importC features to work?
May 16 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 16 May 2022 at 11:55:57 UTC, jmh530 wrote:

 On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 As https://github.com/dlang/dmd/pull/14121 has been merged, 
 the following #ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

 [snip]


 Sorry if this is a dumb question, but when you refer to 
 something as a "ImportC" program, what precisely do you mean? 
 It's a D program that requires importC features to work?


It's just normal C source code compiled with the ImportC compiler.
May 16 2022
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 16 May 2022 at 12:07:04 UTC, Mike Parker wrote:

 On Monday, 16 May 2022 at 11:55:57 UTC, jmh530 wrote:

 On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:

 As https://github.com/dlang/dmd/pull/14121 has been merged, 
 the following #ImportC program can now be compiled and run:

   #include <stdio.h>

   void main()
   {
     printf("hello ImportC!\n");
   }

 [snip]


 Sorry if this is a dumb question, but when you refer to 
 something as a "ImportC" program, what precisely do you mean? 
 It's a D program that requires importC features to work?


 It's just normal C source code compiled with the ImportC 
 compiler.


Thanks. I was confused because I thought "void main" was a D 
thing and not a C thing.
May 16 2022
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 16 May 2022 at 12:28:59 UTC, jmh530 wrote:


 Thanks. I was confused because I thought "void main" was a D 
 thing and not a C thing.


Yeah, it's not part of the C standard. I don't know if ImportC 
allows it as a compiler extension or if Walter wrote it by 
mistake.
May 16 2022