• rempas (7/7) Apr 21 2021 I'm really wondering, what stops us about using mixins in
• Mike Parker (8/15) Apr 21 2021 The whole point of a mixin is to dynamically generate code at
• Kagamin (2/8) Apr 21 2021 rdmd does that, runs a program from source.
• Dukc (8/15) Apr 22 2021 Having runtime mixins in the default language would the downside
• H. S. Teoh (20/35) Apr 22 2021 I've written programs that invoke `dmd` to compile fragments of D code.

rempas <rempas tutanota.com> writes:

I'm really wondering, what stops us about using mixins in 
run-time? I'm really interested on learning how they work. For my 
understating, the write the code for use in compile-time and then 
the whole things is compiled. However, I'm really wondering what 
stops us for writing the code and compiling it at run-time like 
it's an interpreter. Anyone that can explain how things work to 
me?

Mike Parker <aldacron gmail.com> writes:

On Wednesday, 21 April 2021 at 07:50:35 UTC, rempas wrote:
 I'm really wondering, what stops us about using mixins in 
 run-time? I'm really interested on learning how they work. For 
 my understating, the write the code for use in compile-time and 
 then the whole things is compiled. However, I'm really 
 wondering what stops us for writing the code and compiling it 
 at run-time like it's an interpreter. Anyone that can explain 
 how things work to me?

The whole point of a mixin is to dynamically generate code at 
compile-time and insert it into your source to be compiled into 
the binary. By definition, that use case doesn't exist at 
runtime. If you had a D interpreter available at runtime, then 
you'd be evaluating D scripts, which is a completely different 
use case. And for that, you can use any scripting language to 
extend your D program.

Kagamin <spam here.lot> writes:

On Wednesday, 21 April 2021 at 07:50:35 UTC, rempas wrote:
 I'm really wondering, what stops us about using mixins in 
 run-time? I'm really interested on learning how they work. For 
 my understating, the write the code for use in compile-time and 
 then the whole things is compiled. However, I'm really 
 wondering what stops us for writing the code and compiling it 
 at run-time like it's an interpreter.

rdmd does that, runs a program from source.

Dukc <ajieskola gmail.com> writes:

On Wednesday, 21 April 2021 at 07:50:35 UTC, rempas wrote:
 I'm really wondering, what stops us about using mixins in 
 run-time? I'm really interested on learning how they work. For 
 my understating, the write the code for use in compile-time and 
 then the whole things is compiled. However, I'm really 
 wondering what stops us for writing the code and compiling it 
 at run-time like it's an interpreter. Anyone that can explain 
 how things work to me?

Having runtime mixins in the default language would the downside 
that the D runtime would have to include a D interpreter. No 
thanks.

Note though, I said in the default language. Having a separate D 
interpreter that would be called as an external program would be 
different thing altogether. To some extent, you can already do 
that by feeding your runtime scripts to rdmd.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Apr 22, 2021 at 09:01:45PM +0000, Dukc via Digitalmars-d wrote:
 On Wednesday, 21 April 2021 at 07:50:35 UTC, rempas wrote:
 I'm really wondering, what stops us about using mixins in run-time?
 I'm really interested on learning how they work. For my
 understating, the write the code for use in compile-time and then
 the whole things is compiled. However, I'm really wondering what
 stops us for writing the code and compiling it at run-time like it's
 an interpreter. Anyone that can explain how things work to me?

 
 Having runtime mixins in the default language would the downside that
 the D runtime would have to include a D interpreter. No thanks.
 
 Note though, I said in the default language. Having a separate D
 interpreter that would be called as an external program would be
 different thing altogether. To some extent, you can already do that by
 feeding your runtime scripts to rdmd.

I've written programs that invoke `dmd` to compile fragments of D code.
It does work, and dmd is fast enough that the pause is often not
noticeable (unless you're doing it in a tight inner loop).  The
fragments are compiled into shared objects and dynamically loaded and
executed by the program.  Ostensibly, one could employ a similar
mechanism to dynamically compile parts of a program at runtime and
integrate these bits of code into itself.

This does introduce a dependency on the availability of a D toolchain in
the user's environment, though.  This may or may not be desirable,
depending on what you're trying to do.  Plus, there may be licensing
issues if you decide to distribute a dmd toolchain along with your
program.  But it can probably be done, should you wish to do so.

Having said that, though, I'm also unsure about the wisdom of supporting
this as a built-in feature in D. That would require shipping a runtime
interpreter or a complete D toolchain in every program, which seems like
overkill for a rather narrow use case.


T

-- 
Старый друг лучше новых двух.