www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D language as script through JVM

reply "Alexey Egorov" <anandamide mail.ru> writes:
I love D Language, I think this is my favorite language. But this 
love is love through distance - i wrote only one program to try D 
in action. This language is not popular at the moment, i still 
have no any people near me who uses it. But now i searching the 
perfect language for scripting purpose, but still not found it.

native support for multi-platform development
Java is perfect, but.. (it will make you laugh) - it is not 
support operator overloading!
Python is ugly
Lua is ugly
and so on...

I think what D can be a perfect script language. Even more, i 
think it will can become very popular language, if it will be 
possible to use it as script language.

I think there is no problems to make, for example, compiler for 
Java Virtual Machine.
I know, you will say what D designed for run-time, as alternative 
to C++, but there is no problem to kill both rabbits - make it 


What you think about it?

With best regards, Alexey Egorov.
Aug 15 2012
next sibling parent "xenon325" <1 mail.net> writes:
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov wrote:

 I think what D can be a perfect script language. Even more, i 
 think it will can become very popular language, if it will be 
 possible to use it as script language.


Try rdmd (http://dlang.org/rdmd.html)

It actually do compilation. But the idea is when compiler is 
lightning-fast (which dmd is), there is no practical difference 
to interpreter.
Though I don't know what the limit in terms of script size is, 
but for sure it's above 1000 lines of code, which will be enough 
for a lot of use cases.



 I think there is no problems to make, for example, compiler for 
 Java Virtual Machine.


I'm not a compiler writer, but I've read recently [1] that .NET 
VM is too limited to implement even  safe D. I would think JVM is 
the same in this regard.



 I know, you will say what D designed for run-time


IIRC actually community was pretty excited when rdmd came out.



[1] 
http://www.reddit.com/r/programming/comments/xm5y0/d_260_released_d_programming_language/c5nqlaz
Aug 16 2012
prev sibling next sibling parent reply "Thiez" <thiezz gmail.com> writes:
On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov wrote:

 I think there is no problems to make, for example, compiler for 
 Java Virtual Machine.


Think again. Like Java, the JVM does not have pointer arithmetic, 
which means there is no straightforward way to write a 
D-to-JVM-bytecode compiler.


 I know, you will say what D designed for run-time, as 
 alternative to C++, but there is no problem to kill both 

 etc.


I don't think D has any chance of replacing Lua at this point. 
Lua can be used in combination with other languages very easily.
Aug 16 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 16 August 2012 at 09:23:18 UTC, Thiez wrote:

 On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov 
 wrote:

 I think there is no problems to make, for example, compiler 
 for Java Virtual Machine.


 Think again. Like Java, the JVM does not have pointer 
 arithmetic, which means there is no straightforward way to 
 write a D-to-JVM-bytecode compiler.


Actually you can do it, if you make use of sun.misc.Unsafe 
package.

http://www.docjar.com/docs/api/sun/misc/Unsafe.html

--
Paulo
Aug 16 2012
parent reply "Thiez" <thiezz gmail.com> writes:
On Thursday, 16 August 2012 at 11:47:56 UTC, Paulo Pinto wrote:

 On Thursday, 16 August 2012 at 09:23:18 UTC, Thiez wrote:

 On Thursday, 16 August 2012 at 00:48:44 UTC, Alexey Egorov 
 wrote:

 I think there is no problems to make, for example, compiler 
 for Java Virtual Machine.


 Think again. Like Java, the JVM does not have pointer 
 arithmetic, which means there is no straightforward way to 
 write a D-to-JVM-bytecode compiler.


 Actually you can do it, if you make use of sun.misc.Unsafe 
 package.

 http://www.docjar.com/docs/api/sun/misc/Unsafe.html

 --
 Paulo


It looks like the 'getAddress' function requires the memory to 
have been obtained using allocateMemory. It seems to me this 
would prevent the (excelllent) builtin gargbage collector from 
working, which would be a waste.

It seems .net would be a better target, but according to the 
thread that xenon325 links to, that either can't be done, or is 
very hard.
Aug 16 2012
parent reply "Alexey Egorov" <anandamide mail.ru> writes:
 It looks like the 'getAddress' function requires the memory to 
 have been obtained using allocateMemory. It seems to me this 
 would prevent the (excelllent) builtin gargbage collector from 
 working, which would be a waste.

 It seems .net would be a better target, but according to the 
 thread that xenon325 links to, that either can't be done, or is 
 very hard.


i don`t know about compilers so much (but with my friend we make 
something like C-scripting language with own virtual machine). 
so, it is impossible to make jvm byte code from D. can you 
explain the reason in more details?
Aug 17 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 17.08.2012 17:24, schrieb Alexey Egorov:

 It looks like the 'getAddress' function requires the memory to have
 been obtained using allocateMemory. It seems to me this would prevent
 the (excelllent) builtin gargbage collector from working, which would
 be a waste.

 It seems .net would be a better target, but according to the thread
 that xenon325 links to, that either can't be done, or is very hard.


 i don`t know about compilers so much (but with my friend we make
 something like C-scripting language with own virtual machine). so, it is
 impossible to make jvm byte code from D. can you explain the reason in
 more details?


The bytecodes supported by the JVM are optimized for the semantics of 
the Java languages.

Only operations that are required to sucessfully compile Java are available.

This means any language targeting the JVM has to somehow map its own
semantics to what is expected by the JVM, sometimes which consections.

In D's case there are many operations, like unsafe code, or the sematics
associated with stack data types, which cannot be implemented by JVM 
instructions.

--
Paulo
Aug 17 2012
parent reply "Alexey Egorov" <anandamide mail.ru> writes:
 In D's case there are many operations, like unsafe code, or the 
 sematics
 associated with stack data types, which cannot be implemented 
 by JVM instructions.


but script must be save, it is no need to do unsafe operations.
Aug 18 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 19 August 2012 at 00:58:25 UTC, Alexey Egorov wrote:

 In D's case there are many operations, like unsafe code, or 
 the sematics
 associated with stack data types, which cannot be implemented 
 by JVM instructions.


 but script must be save, it is no need to do unsafe operations.


Then you are not implementing the language D, but the language's 
subset, safe D.
Aug 19 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 19 August 2012 at 09:27:44 UTC, Paulo Pinto wrote:

 On Sunday, 19 August 2012 at 00:58:25 UTC, Alexey Egorov wrote:

 In D's case there are many operations, like unsafe code, or 
 the sematics
 associated with stack data types, which cannot be implemented 
 by JVM instructions.


 but script must be save, it is no need to do unsafe operations.


 Then you are not implementing the language D, but the 
 language's subset, safe D.


Oh, and forgot to mention that structs wouldn't be allocated in 
stack anyway, even with a JVM's implementation for safe D, thus 
breaking language's semantics.
Aug 19 2012
parent reply "Thiez" <thiezz gmail.com> writes:
On Sunday, 19 August 2012 at 09:28:49 UTC, Paulo Pinto wrote:

 Oh, and forgot to mention that structs wouldn't be allocated in 
 stack anyway, even with a JVM's implementation for safe D, thus 
 breaking language's semantics.


The reference page on structs http://dlang.org/struct.html does 
not appear to contain the word 'stack' at all. It seems to me 
placing structs on the stack would only be important when 
interfacing with C, but I don't think it would matter otherwise; 
as long as the destructor is called when the struct goes out of 
scope, why should the memory location make any difference?

Language semantics should stick to defining what should happen, 
not how it should happen.
Aug 19 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 19 August 2012 at 17:58:03 UTC, Thiez wrote:

 On Sunday, 19 August 2012 at 09:28:49 UTC, Paulo Pinto wrote:

 Oh, and forgot to mention that structs wouldn't be allocated 
 in stack anyway, even with a JVM's implementation for safe D, 
 thus breaking language's semantics.


 The reference page on structs http://dlang.org/struct.html does 
 not appear to contain the word 'stack' at all. It seems to me 
 placing structs on the stack would only be important when 
 interfacing with C, but I don't think it would matter 
 otherwise; as long as the destructor is called when the struct 
 goes out of scope, why should the memory location make any 
 difference?

 Language semantics should stick to defining what should happen, 
 not how it should happen.


It is described in the TDPL book.

It is important because it influences the amount of memory a 
program may use, and hence invalidate the usability of an 
algorithm that depend on how the memory is used. Memory location 
has as side effects cache location, and access time.

--
Paulo
Aug 19 2012
prev sibling parent "Gustavo Vasquez" <ghvgma gmail.com> writes:
Se hace imprescindible la traducción de los manuales de 
referencia a español y a otros muchos idiomas....he buscado 
información en español y no he encontrado nada mas allá de 
algún articulo donde se promueven las bondades de este lenguaje 
de programación...

Con manuales y documentación en general disponibles en varios 
idiomas les aseguro que la popularidad de D como lenguaje de 
programación se extendería ampliamente.
Aug 19 2012