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 think you misunderstood the nature of my misunderstanding.
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).


 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.


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).


 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.


 
 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