www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D interpreter

reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Hi,
   Seeing the link:

http://www.d-programming-language.org/ 

posted in another thread reminded me that DMD sports a nifty D interpreter.
Something I always wanted for C++ incidentally. With all the talk on virtual
machines recently I was wondering how the D interpreter works. 

Does it compile and run?  or use the embedded interpreter used for compile time
evaluation? are these one and the same?

What happens with imports? Are they interpreted or compiled on the fly or
required to exist already?

I know I should really try the experiment and find some of this out for myself.

How hard would it be to duplicate this behaviour in the gdc front end?
Oct 24 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bruce Adams" <tortoise_74 yeah.who.co.uk> wrote in message 
news:ffo90d$sgo$1 digitalmars.com...
 Hi,
   Seeing the link:

 http://www.d-programming-language.org/

 posted in another thread reminded me that DMD sports a nifty D 
 interpreter. Something I always wanted for C++ incidentally. With all the 
 talk on virtual machines recently I was wondering how the D interpreter 
 works.

 Does it compile and run?  or use the embedded interpreter used for compile 
 time evaluation? are these one and the same?

 What happens with imports? Are they interpreted or compiled on the fly or 
 required to exist already?

 I know I should really try the experiment and find some of this out for 
 myself.

 How hard would it be to duplicate this behaviour in the gdc front end?

It's not so much an interpreter as it is const-folding on steroids. The "interpreter" only works with a subset of language features. Mostly, non-member functions which don't use dynamic memory. This is only used to do CTFE. In fact, go to the "functions" section of the spec, and at the end, it explains all about CTFE and what's allowed/disallowed. Nothing has to be done with GDC because DMD and GDC have exactly the same frontend, they only differ in the backend (optimization and machine code generation). GDC has CTFE too.
Oct 24 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Jarrett Billingsley Wrote:

 "Bruce Adams" <tortoise_74 yeah.who.co.uk> wrote in message 
 news:ffo90d$sgo$1 digitalmars.com...
 Hi,
   Seeing the link:

 http://www.d-programming-language.org/

 posted in another thread reminded me that DMD sports a nifty D 
 interpreter. Something I always wanted for C++ incidentally. With all the 
 talk on virtual machines recently I was wondering how the D interpreter 
 works.

 Does it compile and run?  or use the embedded interpreter used for compile 
 time evaluation? are these one and the same?

 What happens with imports? Are they interpreted or compiled on the fly or 
 required to exist already?

 I know I should really try the experiment and find some of this out for 
 myself.

 How hard would it be to duplicate this behaviour in the gdc front end?

It's not so much an interpreter as it is const-folding on steroids. The "interpreter" only works with a subset of language features. Mostly, non-member functions which don't use dynamic memory. This is only used to do CTFE. In fact, go to the "functions" section of the spec, and at the end, it explains all about CTFE and what's allowed/disallowed. Nothing has to be done with GDC because DMD and GDC have exactly the same frontend, they only differ in the backend (optimization and machine code generation). GDC has CTFE too.

I hoped that the -run option of DMD might make it operate as an interpreter. It sounds like it does but only in the sense of compile then run the result which is half way there. gdc doesn't have quite the same front end in that it use the gcc command line options (which I and my gnu loving kin prefer) but of course it does have the same compiler front end so everything you say about CTFE applies. Regards, Bruce.
Oct 24 2007
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Bruce Adams wrote:
 Hi,
    Seeing the link:
 
 http://www.d-programming-language.org/ 
 
 posted in another thread reminded me that DMD sports a nifty D interpreter.
Something I always wanted for C++ incidentally. With all the talk on virtual
machines recently I was wondering how the D interpreter works. 
 
 Does it compile and run?  or use the embedded interpreter used for compile
time evaluation? are these one and the same?
 
 What happens with imports? Are they interpreted or compiled on the fly or
required to exist already?
 
 I know I should really try the experiment and find some of this out for myself.
 
 How hard would it be to duplicate this behaviour in the gdc front end?
 

The -run flag of DMD is anything but an interpreter. It's just a quick way to run the binary after you've compiled it. It has all the same semantics as compiling software with DMD directly, including all the fun of imports. The CTFE interpreter is extremely limited (and slow). rebuild has a similar flag, but of course handles imports. I believe the gdmd wrapper of GDC already has this functionality. - Gregor Richards
Oct 24 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Gregor Richards Wrote:

 Bruce Adams wrote:
 Hi,
    Seeing the link:
 
 http://www.d-programming-language.org/ 
 
 posted in another thread reminded me that DMD sports a nifty D interpreter.
Something I always wanted for C++ incidentally. With all the talk on virtual
machines recently I was wondering how the D interpreter works. 
 
 Does it compile and run?  or use the embedded interpreter used for compile
time evaluation? are these one and the same?
 
 What happens with imports? Are they interpreted or compiled on the fly or
required to exist already?
 
 I know I should really try the experiment and find some of this out for myself.
 
 How hard would it be to duplicate this behaviour in the gdc front end?
 

The -run flag of DMD is anything but an interpreter. It's just a quick way to run the binary after you've compiled it. It has all the same semantics as compiling software with DMD directly, including all the fun of imports.

Ah I was hoping for D doubling as a dynamic language. Oh well.
 The CTFE interpreter is extremely limited (and slow).

Maybe it should use a VM? :)
 rebuild has a similar flag, but of course handles imports.
 
 I believe the gdmd wrapper of GDC already has this functionality.
 
   - Gregor Richards

Ah never heard of that one before I see it does pretty much what you say - compile and run. Regards, Bruce.
Oct 24 2007
next sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Bruce Adams Wrote:

 Gregor Richards Wrote:
 
 Bruce Adams wrote:
 Hi,
    Seeing the link:
 
 http://www.d-programming-language.org/ 
 
 posted in another thread reminded me that DMD sports a nifty D interpreter.
Something I always wanted for C++ incidentally. With all the talk on virtual
machines recently I was wondering how the D interpreter works. 
 
 Does it compile and run?  or use the embedded interpreter used for compile
time evaluation? are these one and the same?
 
 What happens with imports? Are they interpreted or compiled on the fly or
required to exist already?
 
 I know I should really try the experiment and find some of this out for myself.
 
 How hard would it be to duplicate this behaviour in the gdc front end?
 

The -run flag of DMD is anything but an interpreter. It's just a quick way to run the binary after you've compiled it. It has all the same semantics as compiling software with DMD directly, including all the fun of imports.

Ah I was hoping for D doubling as a dynamic language. Oh well.

Actually the only thing missing to make this work is a cleverer import. One which could trigger compilation either when read or with more complexity "just in time". This feature might also make build management simpler. It would be a cool blurring of the line between a compiled and an interpreted language but no doubt you'll all reply telling me what a sick puppy I am and why. :) Regards, Bruce. Just let me at that front end and I'll have some fun hacking it in to a pseudo-interpreter - muhaha.
Oct 24 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bruce Adams Wrote:
 Gregor Richards Wrote:
 The CTFE interpreter is extremely limited (and slow).

Maybe it should use a VM? :)

That sounds like a lot of work & overhead for what basically ammounts to constant folding. Remember, CTFE is a compile-time optimization, not a way to execute the program. That said, CTFE with a GC and heap-allocation support would be nice, since my code uses a lot of objects.
Oct 24 2007
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Robert Fraser wrote:
 Bruce Adams Wrote:
 Gregor Richards Wrote:
 The CTFE interpreter is extremely limited (and slow).


That sounds like a lot of work & overhead for what basically ammounts to constant folding. Remember, CTFE is a compile-time optimization, not a way to execute the program. That said, CTFE with a GC and heap-allocation support would be nice, since my code uses a lot of objects.

CTFE is limited and problematic enough that it feels like some kind of stop-gap measure to me. I'd feel better if it was eventually going to be replaced by something more elegant. Something like the compiler compiling the CTFE code and dynamic linking to it, then calling it as needed. I know there are security concerns about this, but just address them. No ASM, no external linking except for "safe" things like the stdlib, no pointer manipulations that could access the compiler's memory space, etc. But jeeze, let us use arrays and classes.
Oct 24 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
Chad J wrote:
 Robert Fraser wrote:
 Bruce Adams Wrote:
 Gregor Richards Wrote:
 The CTFE interpreter is extremely limited (and slow).


That sounds like a lot of work & overhead for what basically ammounts to constant folding. Remember, CTFE is a compile-time optimization, not a way to execute the program. That said, CTFE with a GC and heap-allocation support would be nice, since my code uses a lot of objects.

CTFE is limited and problematic enough that it feels like some kind of stop-gap measure to me. I'd feel better if it was eventually going to be replaced by something more elegant. Something like the compiler compiling the CTFE code and dynamic linking to it, then calling it as needed. I know there are security concerns about this, but just address them. No ASM, no external linking except for "safe" things like the stdlib, no pointer manipulations that could access the compiler's memory space, etc. But jeeze, let us use arrays and classes.

You can use array, associative arrays and structs (literals). It's not 'just' about constant folding, with the ability to manipulate strings and insert them as string mixins as code at compile time, you can do code generation. Don Clugston has made a compile time vectorizer which generates optimal assembly from vector expressions. What you want looks like multi-stage programming (but restricted to compile time): http://www.cs.rice.edu/~taha/MSP/
Oct 26 2007