DMD as a library package can now run through all semantic phases

[rikki cattermole]

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