May 14, 2022
On 14/05/2022 6:44 AM, Walter Bright wrote:
> cpp and cl all have the ability to emit all the macro definitions to stdout at the end of a run. (I intend to add it to sppn.) The idea is to intercept that output, look for #define patterns we can deal with, and deal with them.

I must admit, that would have been some good information to have a year ago.
May 14, 2022

On Saturday, 14 May 2022 at 01:42:21 UTC, Walter Bright wrote:

>

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.

Just extend D so that it accepts C code, then macro expansion will work. You are 90% there already.

Or rather, extend C so that it accepts D code.

So when you expand $MACRONAME(param) you inject a C-context that accepts D mixed in.

Should work 99.9% of the time. That is good enough, now you only have to manually deal with 1 in 1000. 90% is not good enough, as that means dealing manually with 1 in 10...

May 14, 2022
I had a similar idea very early on.

Since the compiler understands the difference between a D and C scope, it could mix them.

But I think there will be issues surrounding it. It won't work in a lot of cases.

Adam's mixinC idea is much more likely to "just work" in all cases that I think that is the direction we ought to be going in.
May 14, 2022

On Saturday, 14 May 2022 at 05:45:03 UTC, rikki cattermole wrote:

>

Adam's mixinC idea is much more likely to "just work" in all cases that I think that is the direction we ought to be going in.

What will it look like in macro intensive code? If you end up writing C then the point is lost. What do you do with macros that expand function signatures followed by a body?

The only solution that can work in most cases is to align D more with C (or rather the oppsite) and reflect that in the AST.

May 14, 2022

On Saturday, 14 May 2022 at 05:58:48 UTC, Ola Fosheim Grøstad wrote:

>

On Saturday, 14 May 2022 at 05:45:03 UTC, rikki cattermole wrote:

>

Adam's mixinC idea is much more likely to "just work" in all cases that I think that is the direction we ought to be going in.

What will it look like in macro intensive code? If you end up writing C then the point is lost. What do you do with macros that expand function signatures followed by a body?

The only solution that can work in most cases is to align D more with C (or rather the oppsite) and reflect that in the AST.

You need to do the macro expansion in the lexer, then inject C/D context switch tokens used by the parser, then you inject C/D AST nodes if there are semantic differences, or annotate AST nodes with the differences. That way you can have a C signature followed by a D body.

Anything short of this is a waste of time IMHO.

The last thing the language needs is clunky interop.

May 14, 2022

On Saturday, 14 May 2022 at 06:24:15 UTC, Ola Fosheim Grøstad wrote:

>

You need to do the macro expansion in the lexer, then inject C/D context switch tokens used by the parser, then you inject C/D AST nodes if there are semantic differences, or annotate AST nodes with the differences. That way you can have a C signature followed by a D body.

Technically it migh be better to not use context switch tokens, but instead reserve a bit in the token to distinguish between C and D. Then the parser can swallow either one where there are no semantic differences. These are details though...

May 14, 2022

I also think people see a language that is 20 years old with the toolset and libraries it has and assume that this is all the progress that has been made and that progress must be slow. They may not know about all the corpses of libraries and tools strewn along the way. They might think this is it. That is just speculation, though.

May 14, 2022
On 03/11/2021 7:42 PM, mw wrote:
> -- apache-thrift-d, LDC has build failure, because this bug (logged for 4 months now):
> 
> https://issues.dlang.org/show_bug.cgi?id=22083
> 
> 
> -- D grpc client cannot talk to Python grpc server, because this bug (logged for a year now):
> 
> https://github.com/huntlabs/grpc-dlang/issues/15
> 
> 
> BTW, apache-thrift and grpc are the most important two rpc frameworks used in the industry.

#dbugfix
May 14, 2022

On Saturday, 14 May 2022 at 05:04:40 UTC, Ola Fosheim Grøstad wrote:

>

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?

Bolting on clang is the wrong approach, one has to integrate with it to get the full featureset.

What do you mean? We should try to get D inside Clang? Emit C++ instead of machine code, and feed that to Clang?

May 14, 2022

On Saturday, 14 May 2022 at 10:44:39 UTC, Tejas wrote:

>

We should try to get D inside Clang?

I think D should forget about C++ and do C interop well. Too late to go for C++ now, better to do one thing well once the decision has been made to focus on C.