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

[Amorphorious]

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)

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