www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE and Wasm

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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?
Apr 30 2022
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 30 April 2022 at 07:08:48 UTC, Ola Fosheim Grøstad 
wrote:

 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.


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:

```D
//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))
   { //...
   }
}
```


 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.


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.


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

 What do you think?


Complex and not needed, for reasons above.
Apr 30 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 30 April 2022 at 08:51:26 UTC, Dukc wrote:

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

 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.


 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.


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?


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


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!
Apr 30 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 30 April 2022 at 09:04:34 UTC, Ola Fosheim Grøstad 
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?


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.
Apr 30 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 30 April 2022 at 09:50:26 UTC, Dukc 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.


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.


 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.


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.


 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.


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.
Apr 30 2022
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 30 April 2022 at 07:08:48 UTC, Ola Fosheim Grøstad 
wrote:

 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?


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.
Apr 30 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 30 April 2022 at 09:48:22 UTC, Stefan Koch 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.


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