I understand why both D and C++ users make a fuzz about CTFE, it gives them a feeling of being able to extend the type system or language in a way they are used to. However they are still at wn disadvantage to more powerful languages that allow construction of new types at runtime and do CTFE as an optimization.

Reason 1: compilation performance.
Reason 2: poor debugging tooling.

I'd say you don't have a proper CTFE solution until you can set breakpoints in all functions and see what goes on.

One possibility is to reuse WASM infrastructure by compiling CTFE functions to WASM and use source maps for debugging.

What do you think?

On Saturday, 30 April 2022 at 07:08:48 UTC, Ola Fosheim Grøstad wrote:

No, we're not at a disadvantage. If CTFE was just an optimisation, it'd mean we could not use it to compute values that have to be compile-time by definition. Example:

//CTFE-able function
@safe pure size_t neededSize(size_t a, size_t b)
{ //Whatever...
}

struct SomeTemplateStruct(T)
{ //This wouldn't be possible without CTFE built in to semantics
  ubyte[neededSize(T.sizeof, 4)] anArray;

  //Neither would this
  static if(neededSize(T.sizeof, 8))
  { //...
  }
}

You can still execute the CTFE-able functions at runtime when these are what you prefer.

And nothing prevents the compiler backend from optimising the calculations to compile time even when they are semantically runtime, which I understand is what you're advocating.

Complex and not needed, for reasons above.

On Saturday, 30 April 2022 at 08:51:26 UTC, Dukc wrote:

A language that allows everything to happen at runtime has no such hardcoded requirement. It has the advantage of fast compilation of debug builds and being able to debug those using the same debugging straregy as regular code.

That is an advatage, obviously?

What I am talking about is deceloping and debugging larger applications without limiting metaprogramming.

You can debug individual CTFE functions at runtime in your unit tests, but you cannot "probe" suspected failure points in the bulid of a full application. Big difference!

On Saturday, 30 April 2022 at 07:08:48 UTC, Ola Fosheim Grøstad wrote:

You could write a webasm backend for newCTFE.
That is actually what newCTFE was designed to support.
It translates the frontend AST into a simpler IR.
Which can then be more easily translated into WASM or LLVM or whatever.
I haven't rebased my branch in a while but if someone wants to work on it they should feel free fork it and do so.

On Saturday, 30 April 2022 at 09:04:34 UTC, Ola Fosheim Grøstad wrote:

I think I now get it. You're talking about making D a fully interpreted language, capable of inspecting types and compiling code at runtime. That'd be great. But it'd also be a very big project to implement.

Perhaps, just perhaps, I could see it to happen if it meant embedding DMD as an optional component to DRuntime, and any runtime code generation would invoke it.

But devising a WASM or LLVM intermediate representation system for the langauge is just way beyond what we could tackle with the present contributor force.

On Saturday, 30 April 2022 at 09:50:26 UTC, Dukc wrote:

That would be one way to do it, and that would allow for more easy protyping of language changes, but what I am suggesting is to make the compiler a service with a debug port that allows you to inspect the meta programming "resolution". Since Google has made webasm debuggable for any language using source maps, then that could be an option.

Think more like this: the compiler is a server that allows you to hook into its internals. One way is to think of the compiler as a webserver with a remote client running in a browser that allows you to set breakpoints and get info about what is going on. Thanks to source maps that client can be very simple.

I get that, but it is at least an idea worth thinking about: leveraging existing technology for jailed execution of code to get better tooling.

On Saturday, 30 April 2022 at 09:48:22 UTC, Stefan Koch wrote:

So it could be somehing to think about when/if you get newCTFE merged.