On Wednesday, 20 December 2023 at 03:49:30 UTC, Richard (Rikki) Andrew Cattermole wrote:

We currently have a chain of compilers if you want to bootstrap
latest compiler from C++.

From where I stand, it looks like someone tried to tweak the GC and memory allocation in a non-portable ubeRc0ol way inside of the DMD source code. Which made it incompatible with GDC 11, but who cares? Supposedly this is intended to make the compiler faster. Yet the DMD compiler falls flat on its face due to mundane reasons in a simple compilation speed dependent benchmark: https://forum.dlang.org/thread/fqziujkpdbivsqxsgszu@forum.dlang.org

My alternative mundane suggestion would be to just fix the DMD code on github, so that it can be compiled with GDC 11 again. And then add GDC 11 to the CI in order to prevent it from breaking again in the future.

GDC 11 includes both druntime and phobos. There's no need to have the glue code per version of the backend as long as GDC is maintained as a part of GCC.

Again, my suggestion is to take the C++ implementation of the D frontend from GDC 11. Rebrand it into "D language 2017 edition" and add it back to the mainline GCC. Treat this frontend as a separate programming language and maintain it independently from the "modern D" frontend. But if the community is not interested in a properly maintained "2017 edition" of D language, then this idea is naturally dead.

Could you please clarify this statement?

So now some sort of an ubeRc0ol transpiler from D to C++ is a magic solution?

On Wednesday, 20 December 2023 at 02:33:37 UTC, Steven Schveighoffer wrote:

I'm confused by what you mean by this. I can't recall seeing a DIP 1036e specification, just an implementation and examples. YADIP had a specification, but was superseded by 1036e.

On Wednesday, 20 December 2023 at 14:01:00 UTC, Richard (Rikki) Andrew Cattermole wrote:

Yes, if somebody is contributing a patch for GCC 14, then they can't immediately rely on a newly added fancy GCC 13 feature, but have to ensure that the code still can be successfully compiled by GCC 11, GCC 12 and GCC 13. Even older versions may or may not work, but this is not guaranteed.

GDC 15 won't have an obligation to be compilable by GDC 11. But this doesn't mean that GDC 15 (or DMD) suddenly needs to intentionally break compatibility with GDC 11.

  -HCd=<directory>  write C++ 'header' file to directory
  -HCf=<filename>   write C++ 'header' file to filename

GDC 11 can successfully compile the following code:

import std.stdio, std.string, std.range, std.algorithm, std.conv;
void main() @safe {
  "1, 2, 3, 4, 5".splitter(',').map!(x => x.strip.to!int).sum.writeln;
}

Can a hypothetical D to C++ transpiler do the same?

I don't suggest to rewrite the DMD compiler code in this style, but introducing a transpiler would force DMD developers to be limited to some sort of a "worseD" subset of the D language. Also the transpiler itself is an extra weak link and a potential source of bugs.

On Wednesday, 20 December 2023 at 13:40:00 UTC, jmh530 wrote:

Walter incorrectly read the YAIDIP specification. There was a hope that by implementing it https://github.com/dlang/dmd/pull/15714, it'd clear up the misconceptions.

After implementing the YAIDIP, as written, I decided to go ahead and fix some of its shortcomings, and opened that as a separate PR https://github.com/dlang/dmd/pull/15715 which I called 1036e, since it is a bit closer in design to 1036, but enhanced with ideas from YAIDIP.

The implementations of all three (these two and Walter's own DIP1027) ever very similar. Even to the point of me and Walter using - purely coincidentally - almost exactly the same tricks.

Look at how MixinExp is used in both of these diffs, for example:

https://github.com/dlang/dmd/pull/15715/files#diff-a556a8e6917dd4042f541bdb19673f96940149ec3d416b0156af4d0e4cc5e4bd

https://github.com/dlang/dmd/pull/15722/files#diff-a556a8e6917dd4042f541bdb19673f96940149ec3d416b0156af4d0e4cc5e4bd

I marked it as "FIXME" in mine, figuring it was a quick and easy hack to make it work, but surely there was a better way. Then I looked at Walter's, and he did exactly the same thing!

The biggest difference between the implementations is Walter's says things like:

"// Note: doesn't deal with Unicode code units in identifiers" and "// Note: parsing is crude; not handling parens in literals"

Whereas mine handles all these correctly (as you can see in the unit tests included in my PR) thanks to doing lexing in the lexer, reusing all that existing machinery instead of crudely reinventing it: https://github.com/dlang/dmd/pull/15715/files#diff-b893f1fe9a8dab286d255483a3dd8cd982bc321c655ab2be5f8d14402aeea5be

But they're still built on the same concepts, and in many places, almost the same code! The core of the implementation is quite simple: lex the string, using sub-lexers for the interpolated elements, then lower to a tuple of the elements. There's even comments in the code showing the idea.

A big reason why my diff is bigger is that my PR includes user-facing documentation comments: https://github.com/dlang/dmd/pull/15715/files#diff-22dd3c85816b0aa6351d1bc21e72ed410b509f8f7c768db3dd974967751b37e1 which further, along with the half dozen examples of use cases I wrote up (separately, but also including some design rationale https://github.com/adamdruppe/interpolation-examples/#feature-design-faq), help to explain what is going on beyond sharing the same conceptual foundation as the other DIPs.

If you want to know how this works, you can:

1. Read the ddoc included in the PR. This is written for library authors, not compiler implementers, so hopefully it is accessible.

2. Read the examples repo. This is written for end users, to show them of the possibilities.

3. Read the comments in the implementation, which explain what the code does in simpler terms than dmd's AST, and the included unit tests which show what is and is not expected to work.

4. Compile it and try it for yourself!

On Saturday, 16 December 2023 at 18:31:23 UTC, Gary Chike wrote:

Ok, what I did was I joined the communities and asked "Is x production ready", and all of them basically said no. But I guess it's a matter of perspective.

On Wednesday, 20 December 2023 at 15:33:40 UTC, Adam D Ruppe wrote:

Thanks for the detailed explanation, but I think Walter will still come back with the response from before...