digitalmars.D - D language as script through JVM
- "Alexey Egorov" <anandamide mail.ru> Aug 15 2012
- "xenon325" <1 mail.net> Aug 16 2012
- "Thiez" <thiezz gmail.com> Aug 16 2012
- Paulo Pinto <pjmlp progtools.org> Aug 17 2012
- "Paulo Pinto" <pjmlp progtools.org> Aug 16 2012
- "Thiez" <thiezz gmail.com> Aug 16 2012
- "Alexey Egorov" <anandamide mail.ru> Aug 17 2012
- "Alexey Egorov" <anandamide mail.ru> Aug 18 2012
- "Paulo Pinto" <pjmlp progtools.org> Aug 19 2012
- "Paulo Pinto" <pjmlp progtools.org> Aug 19 2012
- "Thiez" <thiezz gmail.com> Aug 19 2012
- "Gustavo Vasquez" <ghvgma gmail.com> Aug 19 2012
- "Paulo Pinto" <pjmlp progtools.org> Aug 19 2012
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. C# good language, almost perfect for me, except of that have no 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 good alternative for Python, Lua, Java, C#, etc. What you think about it? With best regards, Alexey Egorov.
Aug 15 2012
"xenon325" <1 mail.net> 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
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 rabbits - make it good alternative for Python, Lua, Java, C#, 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
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
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
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
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
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
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
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
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
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
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