On Tuesday, 30 November 2021 at 14:46:59 UTC, Ola Fosheim Grøstad wrote:

What about the shortage of manpower?
How to arrange manpower?

On Tuesday, 30 November 2021 at 14:58:02 UTC, zjh wrote:

There are several people writing compilers for either D or D-like languages already…

With a clean code base, that is more contemporary, with a more modular architecture, more people would be interested in working on the compiler.

On Tuesday, 30 November 2021 at 14:46:59 UTC, Ola Fosheim Grøstad wrote:

Such as with -preview/-revert then?

Can you give an example of breaking changes that this .d3 trick allows, that cannot be covered by -preview/-revert?

On Tuesday, 30 November 2021 at 19:56:01 UTC, Guillaume Piolat wrote:

This is possible:

1. -preview-d3-feature-X on the D2 side

2. -emulate-d2-feature-Y on the D3 side for common "deprecated" features.

3. Allow subsystems compiled with both D2 and D3 to be combined using high level intermediate representation (HIR) so that you can transition one subsystem at a time from D2 to D3. Although, you might have to replicate some templates on both sides because I doubt that "static if" is suitable for HIR.

You have to decide case-by-case what is worthwhile. It has to be based on what existing code-authors find difficult.

If you create a new modular frontend and follow a clean spec, then you will get many differences all at once. Anything that depends on "does-this-compile-traits" could break even if you try to emulate DMD. The alternative is to reimplement all quirks of the current frontend and that could have a negative complexity impact and a development time impact, basically not making it worthwhile.

All changes that are cleaning up language semantics, can potentially break things such as traits. When you move something to a library or change things you will affect those that do "shoehorn tricks" with the language.

You should probably only aim for ease of transition for people who write good code. People who rely on trickery are very costly to support.

Anyway, «D3» is inevitable if the current compiler is difficult to evolve, maybe it already «exists» in the shape of another language with no affiliation to D.

On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:

What you basically are asking for is C with ast macros.

-Alex

On Wednesday, 1 December 2021 at 15:01:10 UTC, 12345swordy wrote:

Can you emulate D as C with AST macros?

On Wednesday, 1 December 2021 at 15:09:28 UTC, Ola Fosheim Grøstad wrote:

https://github.com/eudoxia0/cmacro

Why not try it out yourself.

On Thursday, 2 December 2021 at 00:58:38 UTC, 12345swordy wrote:

That would be a different language. Templates are related to AST macros, but they are limited to expanding on"!".

On Thursday, 2 December 2021 at 09:20:26 UTC, Ola Fosheim Grøstad wrote:

Exactly

On Thursday, 2 December 2021 at 09:20:26 UTC, Ola Fosheim Grøstad wrote:

The syntax used for macro expansion is a trivial detail. Rust has "real" AST macros, and they also use ! for expansion (vec!, println!, etc.).

The biggest difference between AST macros and templates is that expanding a template both generates code and binds that code to a symbol in a particular scope.