I hava a feature request.  Maybe it is a bad idea.
You could create a D interpreter.  Rather than having
to compile D each time and then run it you could have
a D interpreter.  This way if you wanted to test a D
program it could be run by the D interpreter (AKA Perl)
without having to compile a D program.  Maybe this would
be too much work.  But it would give D the power to be compiled
or interpreted and run as a script language.

ie.

home directory:
-rwxrwxrwx    1 usr  1000 Jan 11 12:10 helloworld.d
-rwxrwxrwx    1 usr  1233 Jan 11 12:10 makefile
-rwxrwxrwx    1 usr  1455 Jan 11 12:10 include.d
home:% d helloworld.d
Helloworld!!!!
home:%

Makes sense. I think that some simplified D makes a better scripting language as EcmaScript within D environment.

Integration is important. I have been reading about EcmaScript and its integration with Java. Sure, EcmaScript (or any other scripting language) in D could go the same way, and import D created classes and objects. It is possible even as library in the current compilers due to ClassInfo tags and static class prototypes. But how about handling objects created by script in a main programme? I imagine it being very awkward.

Some features which are not requiered in the interpreter are templates and other advanced features. However, strong typing might be good since it has to interact with a strong-typed environment anyway. Making it weakly typed would make a run-time compiled implementation senseless. A variant variable type can be simply implemented in D and be called "var", switching between a string, numeric types, and objects. Burton has already implemented a "generic" type with such behaviour. Or should var be reserved for a simple type inference?

However, some interpreted languages are suitable to be run in an interactive frontend. D is not(?), since its compilation requieres knowledge about the whole program. (???)

I'll try to hack something together as soon as i have time. That is not very soon. :)

As for making what you propose, a platform-independant D bytecode compiler can be created as a backend to Walter's DMD source. Maybe it wouldn't be hard. But if it's  being done, why not generate .NET bytecode, which can be compiled on many platforms? A .NET compiler/interpreter VM can be shipped without libraries or with standard D libraries for that purpose. Compiling to .NET might be harder though. (?)

-i.

Kublai Kahn wrote:
> I hava a feature request.  Maybe it is a bad idea.
> You could create a D interpreter.  Rather than having
> to compile D each time and then run it you could have
> a D interpreter.  This way if you wanted to test a D
> program it could be run by the D interpreter (AKA Perl)
> without having to compile a D program.  Maybe this would
> be too much work.  But it would give D the power to be compiled
> or interpreted and run as a script language.
> 
> ie.
> 
> home directory:
> -rwxrwxrwx    1 usr  1000 Jan 11 12:10 helloworld.d
> -rwxrwxrwx    1 usr  1233 Jan 11 12:10 makefile
> -rwxrwxrwx    1 usr  1455 Jan 11 12:10 include.d
> home:% d helloworld.d Helloworld!!!!
> home:%

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b3ol2o$8v0$1@digitaldaemon.com...
> Makes sense. I think that some simplified D makes a better scripting language as EcmaScript within D environment.

I have been thinking about incorporating DMDScript into D.

You've said that more than once. I have made a mistake: "as" below means "than".

AFAI understand, using D classes from a script should work. But if creation of classes in script is allowed, how woud they be processed by D? Bill Cox, who is an experinced developer in that field and i value that a lot, has proposed extending D classes with run-time added properties which work exactly the way like in EcmaScript, Python and such, which would solve the problem of communication. (i think).

Until that, i have imegined the interface between the host and the script fairly awkward. Like Python-C interface is. That's why i have assumed, a simplified D would be a better scripting language in our case.

-i.

Walter wrote:
> "Ilya Minkov" <midiclub@8ung.at> wrote in message
> news:b3ol2o$8v0$1@digitaldaemon.com...
> 
>>Makes sense. I think that some simplified D makes a better scripting
>>language as EcmaScript within D environment.
> 
> I have been thinking about incorporating DMDScript into D.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b3u7br$qps$1@digitaldaemon.com...
> AFAI understand, using D classes from a script should work. But if creation of classes in script is allowed, how woud they be processed by D? Bill Cox, who is an experinced developer in that field and i value that a lot, has proposed extending D classes with run-time added properties which work exactly the way like in EcmaScript, Python and such, which would solve the problem of communication. (i think).
>
> Until that, i have imegined the interface between the host and the script fairly awkward. Like Python-C interface is. That's why i have assumed, a simplified D would be a better scripting language in our case.

It won't be a seamless fit. Probably only specialized D classes will be available to the script engine.

In article <b3u7br$qps$1@digitaldaemon.com>, Ilya Minkov says...
>
>You've said that more than once. I have made a mistake: "as" below means "than".
>
>AFAI understand, using D classes from a script should work. But if creation of classes in script is allowed, how woud they be processed by D? Bill Cox, who is an experinced developer in that field and i value that a lot, has proposed extending D classes with run-time added properties which work exactly the way like in EcmaScript, Python and such, which would solve the problem of communication. (i think).
>
>Until that, i have imegined the interface between the host and the script fairly awkward. Like Python-C interface is. That's why i have assumed, a simplified D would be a better scripting language in our case.
>
>-i.
>

Jython (Python interpreter in Java) allows Python classes to extend Java classes. It's not awkward. Using a similar model with D should'nt be a problem.