draft proposal for Sum Types for D

[Hipreme]

On Wednesday, 30 November 2022 at 20:54:26 UTC, H. S. Teoh wrote:
> On Wed, Nov 30, 2022 at 08:32:26PM +0000, Hipreme via 
> Digitalmars-d wrote:
>> On Wednesday, 30 November 2022 at 20:01:47 UTC, Guillaume 
>> Piolat wrote:
>> > On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright 
>> > wrote:
>> > > Go ahead, Make My Day! Destroy!
>> > > 
>> > > https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md
>> > 
>> > Would prefer WASM and named arguments to sum types.
>> 
>> Would love to implement Web support for my engine too :D
>
> I haven't had time to look at the two existing wasm projects 
> yet (one by Adam, and the other I forgot by who); have you 
> tried either of them out yet?  How complete/incomplete are 
> they?  How much can you do in them? How close/far are they to a 
> comprehensive WASM support package for D?
>
> I think we should evaluate what we currently have, and lay out 
> a rough plan for how to move forward.
>
> My ideal dream is a WASM support package (build system, helper 
> scripts, HTML/JS generators, etc) that lets me take an existing 
> D program, complete with GC and main(), and compile it into a 
> web app (WASM modules + HTML + JS glue, the latter preferably 
> completely auto-generated, that can be copied into my Apache 
> web directory and it would Just Work(tm)), with minimal / no 
> changes to the code itself.  Fiddly details like passing 
> strings to/from JS, interfacing with web APIs or WASI or 
> whatever, should just be completely automated away by scripts 
> or build system or whatever.
>
> Of course, I think we still have a way to go before we get to 
> this point.  But it would be good to evaluate just where 
> exactly we are right now wrt this ideal dream, so that we can 
> make meaningful steps forward.
>
>
> T

Adam's WASM is a lot easier to a mere mortal to use, it is only a 
matter of including it to the project and build it as ldc wasm 
triple and you're done.
I think the problem Adam's project has is of it being a custom 
druntime so you'll have a lot of pitfalls there and must be 
careful in which features you're using, but it is quite usable 
small projects IMO.

The other is from Sebastian Koppe, which he attempts to port WASI 
as the libc (and thus, making the runtime just work). The problem 
is that you will need to actually build the druntime and wasi 
itself which I wasn't able to get it done for reasons like: WASI 
wasn't building in my PC so I wasn't able to try the runtime.


 From what I remember that Adam said, there was a problem on the 
garbage collection being executed while wasm was running its 
code. IIRC, he said something about deferring the GC, didn't 
quite get the details but he seemed really sure that would solve 
the problems.


>Fiddly details like passing strings to/from JS interfacing with 
>web APIs or WASI or whatever, should just be completely 
>automated away by scripts or build system or whatever.

IIRC, Adam's project had an `eval!` which would be able to do 
that. But I guess having real compiler support and marking the 
function as `extern(System)` could do that. Executing JS defined 
code could even be: `@wasm("the.javascript.function")` or even 
`extern(WebAssembly, "the.javascript.function")` as it would use 
the same syntax from the C++ namespace