On 30/01/2018 5:45 AM, Amorphorious wrote:
> On Tuesday, 30 January 2018 at 04:31:43 UTC, rikki cattermole wrote:
>> On 30/01/2018 4:21 AM, EntangledQuanta wrote:
>>> On Tuesday, 30 January 2018 at 02:04:30 UTC, H. S. Teoh wrote:
>>>> On Tue, Jan 30, 2018 at 01:20:02AM +0000, Bastiaan Veelo via Digitalmars-d wrote:
>>>>> On Tuesday, 30 January 2018 at 00:21:09 UTC, Amorphorious wrote:
>>>>> > Just curious what the point is and what box it opens.
>>>>>
>>>>> Better tooling is what comes to my mind. Imagine your editor to understand your code as good as the compiler itself. I assume this is the primary motivation.
>>>>
>>>> Being able to compile D code in your program (i.e., have an embedded D compiler) is also nice for JIT applications. E.g., fill in a code template with runtime-determined parameters, compile it, and run it at native execution speed.
>>>>
>>>>
>>>> T
>>>
>>> and can it do this? I didn't see anything in the docs that show that it can be used for "scripting", so to speak. Just seemed to be used for semantic analysis and pretty printing. Are these future plans or are they meant to be used as part of simply compiling D code with externally using a dmd compiler bundled with the app(which can already be done)?
>>
>> The backend still isn't fully D, so it won't be a goal short-term.
>> But it should be mostly just hooking up a new target into which it gets put into memory instead of an object file.
>>
>>> It would be really cool to be able to create D scripts in an application directly using a "library" solution. I hope though all can be independent of the GC and OS. I'd like to use it for embedded solutions.
>>
>> D isn't a scripting language, it is native. It will always matter what OS/platform you are compiling to.
> 
> Um, all scripting languages are native. Just because there is an intermediary doesn't mean much except speed. The boundary isn't as well defined as you want to imply. (and don't start and argument about how 95% of people would say scripting is not the same as native... statistics doesn't imply truth. Scripting is a term that is used to imply that an application supports modification through coding, not much more. It's not all that difficult to grasp. It just turns out that most scripting languages use an intermediate compiler or interpreter because that is how things evolved... it doesn't meant that is the only way things can be)

That extra indirection makes a big difference, it means you can't just do a asm { jmp $X; } into the code to run it. D has never been a scripting language, but it is partially interpreted (CTFE).

> 2nd. What I mean is not the binary but the library code itself. Will it only work on windows, for example. As I said, I want to use it for embedded solutions and if it only works for specific platforms then it is of no use to me and as if it didn't exist in the first place. This means that whatever solution it does use is not tied in to phobos too much nor the GC(ideally, not at all).

Oh it'll work on Windows, OSX, BSD and Linux without a doubt.
But embedded has bigger problems then just what the library supports.

Can you even compile for it? For example the only way to compile D to ARM is through gdc and ldc. So great you have the frontend running available to you on an ARM chip, but you can't use dmd's backend there as well.

So no, this will not help you, in the embedded market. Unless of course you feel up to contributing a new backend ;)

On Tue, Jan 30, 2018 at 04:31:43AM +0000, rikki cattermole via Digitalmars-d wrote: [...]
> D isn't a scripting language, it is native. It will always matter what OS/platform you are compiling to.

One could always hook the front end to a codegen that emits bytecode instead of native assembly.  Who knows, perhaps there's already an LLVM codegen that does this, so all you have to do is to specify the right arch to ldc.

The argument about asm{} is moot anyway because it's x86-specific. IIRC, gdc doesn't even support dmd's asm{} syntax; it uses its own gcc-specific asm syntax. In theory, even asm blocks can be translated into, say, LLVM IR, and then retargeted to whatever arch you one, including a VM.


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.

On Tuesday, 30 January 2018 at 15:56:12 UTC, H. S. Teoh wrote:
> On Tue, Jan 30, 2018 at 04:31:43AM +0000, rikki cattermole via Digitalmars-d wrote: [...]
>> D isn't a scripting language, it is native. It will always matter what OS/platform you are compiling to.
>
> One could always hook the front end to a codegen that emits bytecode instead of native assembly.  Who knows, perhaps there's already an LLVM codegen that does this, so all you have to do is to specify the right arch to ldc.

BTW

-enable-dynamic-compile was part of LDC 1.7

https://forum.dlang.org/post/zwksmprgfnyukgsamfql@forum.dlang.org

(It's more suitable for JIT optimization though.)