www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Libdparse with DMD frontend

reply Eugene Wissner <belka caraus.de> writes:
libdparse was created at the time D frontend was written in a 
different language and wasn‘t available as a library.

The D frontend itself isn‘t allowed to adopt the latest D 
features straightaway, because it would make bootstrapping and 
porting to other compilers more complicated than it should be. So 
the frontend should be compilable with an older version of DMD. 
Furthermore it should be compatible with C++, so it can be used 
by GDC and LDC. Therefore DMD is not always pretty and might be 
not the best fit for the high level code and could profit from a 
high-level wrapper.

Can libdparse be such a wrapper? Updating libdparse would 
probably be less painful, because it doesn‘t need to reimplement 
the frontend.
Writing another "libdparse" is not desired because libdparse is 
used by such tools like D-Scanner and becomes actually useful if 
used by that tools.

It is a big change to libdparse, so I‘d like to know if something 
is wrong with it and if the work on it is welcome.
Apr 27 2019
parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 27 April 2019 at 12:55:07 UTC, Eugene Wissner wrote:

 libdparse was created at the time D frontend was written in a 
 different language and wasn‘t available as a library.

 The D frontend itself isn‘t allowed to adopt the latest D 
 features straightaway, because it would make bootstrapping and 
 porting to other compilers more complicated than it should be. 
 So the frontend should be compilable with an older version of 
 DMD. Furthermore it should be compatible with C++, so it can be 
 used by GDC and LDC. Therefore DMD is not always pretty and 
 might be not the best fit for the high level code and could 
 profit from a high-level wrapper.

 Can libdparse be such a wrapper? Updating libdparse would 
 probably be less painful, because it doesn‘t need to 
 reimplement the frontend.
 Writing another "libdparse" is not desired because libdparse is 
 used by such tools like D-Scanner and becomes actually useful 
 if used by that tools.

 It is a big change to libdparse, so I‘d like to know if 
 something is wrong with it and if the work on it is welcome.


I don't believe that this is possible.

   1. offical front end AST is different of dparse AST
   2. dparse uses special stuff for memory allocs

It's only possible in theory. I rather think that at some point a 
new tooling generation could hatch if DMD as a library becomes 
usable.
Apr 27 2019
parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 27 April 2019 at 13:04:06 UTC, Basile B. wrote:

   1. offical front end AST is different of dparse AST


isn't that just a matter of converting one representation into 
another one?
Apr 27 2019
parent reply Amex <Amex gmail.com> writes:
On Saturday, 27 April 2019 at 16:31:24 UTC, Eugene Wissner wrote:

 On Saturday, 27 April 2019 at 13:04:06 UTC, Basile B. wrote:

   1. offical front end AST is different of dparse AST


 isn't that just a matter of converting one representation into 
 another one?


Virtually everything is just converting one representation in to 
another...
Apr 27 2019
parent Eugene Wissner <belka caraus.de> writes:
On Saturday, 27 April 2019 at 20:30:17 UTC, Amex wrote:

 On Saturday, 27 April 2019 at 16:31:24 UTC, Eugene Wissner 
 wrote:

 On Saturday, 27 April 2019 at 13:04:06 UTC, Basile B. wrote:

   1. offical front end AST is different of dparse AST


 isn't that just a matter of converting one representation into 
 another one?


 Virtually everything is just converting one representation in 
 to another...


I mean it is a standard compiler task; also GCC takes AST of a 
frontend and translates it into another AST (I suppose GENERIC), 
it can optimize independent of the source language.
Apr 27 2019