search

dlang / project-ideas

Collection of impactful projects in the D ecosystem
36 stars 12 forks source link

Run Time Function Execution #114

Open Herringway opened 4 months ago

Herringway commented 4 months ago

Description

Now that DMD and druntime are in the same repository and DMD-as-a-library is taking shape, it should be possible to expose CTFE for use at runtime through druntime. RTFE!

What are rough milestones of this project?

How does this project help the D community?

We can enable D to be used as not just an efficient, compilable language, but also as an embeddable scripting language. This gives D a rather unique edge over its competition.

Recommended skills

Point of Contact

References

quickfur commented 4 months ago

Honestly I don't see what this would actually accomplish in practice. What would this achieve that you can't already achieve with launching dmd via std.process to create a shared library, and loading the generated binary (with dlopen, et al, or their equivalents on other OSes) and running the result?

I actually did this in one of my projects, btw; dmd actually runs fast enough that you generally don't notice that it's actually compiling a mini subprogram at runtime. All you need is to ship dmd with your program and you're ready to go. Arguably one could encapsulate this in a neat little library and put it on dub or something so that people could do the same thing with just a couple of lines of code. It doesn't require changing the language at all.

This is not going to let you introspect the current program, of course, but for that what you really need is RTTI, which D already has. Maybe it could be expanded, but then that defeats the entire purpose of compile-time introspection, where the whole point is that it's done at compile-time without the runtime cost. Runtime introspection is indeed possible ala Java, but it comes with compile-time costs. Is that really better than what we already have now?

Herringway commented 4 months ago

Honestly I don't see what this would actually accomplish in practice. What would this achieve that you can't already achieve with launching dmd via std.process to create a shared library, and loading the generated binary (with dlopen, et al, or their equivalents on other OSes) and running the result?

I actually did this in one of my projects, btw; dmd actually runs fast enough that you generally don't notice that it's actually compiling a mini subprogram at runtime. All you need is to ship dmd with your program and you're ready to go. Arguably one could encapsulate this in a neat little library and put it on dub or something so that people could do the same thing with just a couple of lines of code. It doesn't require changing the language at all.

This is not going to let you introspect the current program, of course, but for that what you really need is RTTI, which D already has. Maybe it could be expanded, but then that defeats the entire purpose of compile-time introspection, where the whole point is that it's done at compile-time without the runtime cost. Runtime introspection is indeed possible ala Java, but it comes with compile-time costs. Is that really better than what we already have now?

That solution is not just unnecessarily high-overhead, but it's completely unfeasible on platforms where executing binaries isn't possible. Game consoles, certain app stores, etc.