On 5/13/2022 3:49 PM, forkit wrote:
> on 11. ImportC will actually dissuade people from moving away from C.
> 
> on 13. This too will dissuade people from moving away from C.

People almost *never* translate functioning programs from one language to another. After all, people still use COBOL.


> In essence, you're forever locking C into D. C++ made this mistake too.

The existence of ImportC is a dev environment thing. It doesn't change the specification of D at all.

On Saturday, 14 May 2022 at 00:11:25 UTC, Tejas wrote:
> On Friday, 13 May 2022 at 23:24:14 UTC, Ola Fosheim Grøstad wrote:
>> (D's biggest mistake was to not align semantics with C++ and incorporate clang for C++ interop, but that is too late now.)
>
> +1000!!!!

Well, clearly anyone who did that would have conquered the world.

https://wiki.dlang.org/Calypso

On Friday, 13 May 2022 at 23:45:16 UTC, Walter Bright wrote:
> On 5/13/2022 3:49 PM, forkit wrote:
>> on 11. ImportC will actually dissuade people from moving away from C.
>> 
>> on 13. This too will dissuade people from moving away from C.
>
> People almost *never* translate functioning programs from one language to another. After all, people still use COBOL.
>
>
>> In essence, you're forever locking C into D. C++ made this mistake too.
>
> The existence of ImportC is a dev environment thing. It doesn't change the specification of D at all.

That may be so. I don't disagree.

However, when people say they developed my program in D, nobody really knows what they mean. You'll have to go look at all the source code to see what it really is.

On Saturday, 14 May 2022 at 00:24:49 UTC, Tejas wrote:
>
> Well, do we know why Calypso's development stopped?
>
> Maybe it had nothing to do with the merit of the idea but simply the circumstances of the developers? Many open source projects stall because the devs simply don't have time to maintain it anymore, perhaps the same happened here?

Well, anything the seeks to 'widen and faciliate' C/C++ ... has a limited life time ;-)

On Friday, 13 May 2022 at 19:18:35 UTC, Walter Bright wrote:
> The fact that there are 3 of them suggests shortcomings.

And those shortcomings are...?

The fact there are 3 of them can also be explained by people not investigating existing things before doing their own toy or by maintainers refusing to work together forcing a fork.

Almost everything you listed here already exist in the competition, and what's left could have been done as an automatic build integration (even dmd itself just shelling out.... you know, like it is doing for the preprocessor now...) instead of a whole new compiler.

As I've said several times now, there ARE things importC can potentially do that the others can't. But you said in a previous message:

> Preprocessor metaprogramming macros will never be directly available to D.

It actually CAN work, through a hygienic mixin.

Oh and from that message?

> htod, dstep, and dpp also will simply ignore metaprogramming macros.

That's not true.

They don't always succeed, but they don't simply ignore them. dstep tries to convert some back to D templates and mixins. dpp actually tries to apply them to the complete source (usually mangling the code in the process, but it does NOT ignore them).

I spoke with Atila a year ago on his excellent dpp. He handles the metaprogramming macros with a handbuilt translation of them. This works, but has to be constantly tuned. The lack of a general solution was what I was referring to.

I said I wanted to incorporate his work on this into ImportC's handling of the preprocessor macros.

With this:

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

the following ImportC program compiles and runs:

  #include <stdio.h>
  void main() {
    printf("hello world\n");
  }