Why not make the compiler front-end into a dynamic library?

This would allow other tools to use the same implementation that the compiler itself uses for things like parsing, lexing, and analyzing code trees.  It would solve the problem of our development tools having to be consistently updated to support the latest and greatest additions to the D language.  Why duplicate effort and play the never-ending, ever-losing catch-up game?

Turning the compiler into a library will also have its advantages in writing IDEs !  Imagine calling a function from the compiler to retrieve the token list for a module and easily syntax-highlighting the code from that.  Then it's a few steps away to analyzing the code trees and implementing some sort of code-completion or intellisense easily.  Documentation generators could be written with ease!

What does everyone think?  I can't find a reason *not* to go down this path, but maybe others can...

The library would probably want to have a plain C API that wraps the internal C++ code for the most compatibility (especially with D programs).

Regards,
James Dunne

I think its a great idea. It would save D IDE writers a *lot* of time.

In article <deqajs$1q1u$1@digitaldaemon.com>, James Dunne says...
>
>Why not make the compiler front-end into a dynamic library?
>
>This would allow other tools to use the same implementation that the compiler itself uses for things like parsing, lexing, and analyzing code trees.  It would solve the problem of our development tools having to be consistently updated to support the latest and greatest additions to the D language.  Why duplicate effort and play the never-ending, ever-losing catch-up game?
>
>Turning the compiler into a library will also have its advantages in writing IDEs !  Imagine calling a function from the compiler to retrieve the token list for a module and easily syntax-highlighting the code from that.  Then it's a few steps away to analyzing the code trees and implementing some sort of code-completion or intellisense easily.  Documentation generators could be written with ease!
>
>What does everyone think?  I can't find a reason *not* to go down this path, but maybe others can...
>
>The library would probably want to have a plain C API that wraps the internal C++ code for the most compatibility (especially with D programs).
>
>Regards,
>James Dunne

There is dmdfe http://home.comcast.net/~benhinkle/dmdfe/ , a compilable front end that you can then make into a library if you want.

"James Dunne" <james.jdunne@gmail.com> wrote in message news:deqajs$1q1u$1@digitaldaemon.com...
> Why not make the compiler front-end into a dynamic library?
>
> This would allow other tools to use the same implementation that the
compiler
> itself uses for things like parsing, lexing, and analyzing code trees.  It
would
> solve the problem of our development tools having to be consistently
updated to
> support the latest and greatest additions to the D language.  Why
duplicate
> effort and play the never-ending, ever-losing catch-up game?
>
> Turning the compiler into a library will also have its advantages in
writing
> IDEs !  Imagine calling a function from the compiler to retrieve the token
list
> for a module and easily syntax-highlighting the code from that.  Then it's
a few
> steps away to analyzing the code trees and implementing some sort of code-completion or intellisense easily.  Documentation generators could be written with ease!
>
> What does everyone think?  I can't find a reason *not* to go down this
path, but
> maybe others can...
>
> The library would probably want to have a plain C API that wraps the
internal
> C++ code for the most compatibility (especially with D programs).
>
> Regards,
> James Dunne

In article <detml2$1js2$1@digitaldaemon.com>, Charles says...
>
>There is dmdfe http://home.comcast.net/~benhinkle/dmdfe/ , a compilable front end that you can then make into a library if you want.
>
>"James Dunne" <james.jdunne@gmail.com> wrote in message news:deqajs$1q1u$1@digitaldaemon.com...
>> Why not make the compiler front-end into a dynamic library?
>>
>> This would allow other tools to use the same implementation that the
>compiler
>> itself uses for things like parsing, lexing, and analyzing code trees.  It
>would
>> solve the problem of our development tools having to be consistently
>updated to
>> support the latest and greatest additions to the D language.  Why
>duplicate
>> effort and play the never-ending, ever-losing catch-up game?
>>
>> Turning the compiler into a library will also have its advantages in
>writing
>> IDEs !  Imagine calling a function from the compiler to retrieve the token
>list
>> for a module and easily syntax-highlighting the code from that.  Then it's
>a few
>> steps away to analyzing the code trees and implementing some sort of code-completion or intellisense easily.  Documentation generators could be written with ease!
>>
>> What does everyone think?  I can't find a reason *not* to go down this
>path, but
>> maybe others can...
>>
>> The library would probably want to have a plain C API that wraps the
>internal
>> C++ code for the most compatibility (especially with D programs).
>>
>> Regards,
>> James Dunne
>
>

That defeats the purpose of turning Walter's copy into a library.  Walter always has the bleeding edge compiler.  If dmdfe is turned into a library, its maintainer will always have to play the never-ending ever-losing catch-up game to update it to the current compiler, not to mention refactor it every time a change happens so that it may still be a library.  No this doesn't sound like a good idea, nor does it solve any of the problems I mentioned in the OP.

Regards,
James Dunne

> That defeats the purpose of turning Walter's copy into a library.  Walter
always
> has the bleeding edge compiler.  If dmdfe is turned into a library, its maintainer will always have to play the never-ending ever-losing catch-up
game
> to update it to the current compiler, not to mention refactor it every
time a
> change happens so that it may still be a library.  No this doesn't sound
like a
> good idea, nor does it solve any of the problems I mentioned in the OP.

Yea , as much as Id like to see that also , I don't see it happening, was trying to offer a working alternative.

While DMDFE is at .121 ( I'm actually trying to bring it up to .129 today ) , Ben has made it pretty easy to upgrade it ... and it _is_ a working front end to DMD capable of those things you talked about.  And the front-end is pretty complex, your going to have to get your hands dirty eventually :).

Charlie


"James Dunne" <james.jdunne@gmail.com> wrote in message news:deu610$20ke$1@digitaldaemon.com...
> In article <detml2$1js2$1@digitaldaemon.com>, Charles says...
> >
> >There is dmdfe http://home.comcast.net/~benhinkle/dmdfe/ , a compilable front end that you can then make into a library if you want.
> >
> >"James Dunne" <james.jdunne@gmail.com> wrote in message news:deqajs$1q1u$1@digitaldaemon.com...
> >> Why not make the compiler front-end into a dynamic library?
> >>
> >> This would allow other tools to use the same implementation that the
> >compiler
> >> itself uses for things like parsing, lexing, and analyzing code trees.
It
> >would
> >> solve the problem of our development tools having to be consistently
> >updated to
> >> support the latest and greatest additions to the D language.  Why
> >duplicate
> >> effort and play the never-ending, ever-losing catch-up game?
> >>
> >> Turning the compiler into a library will also have its advantages in
> >writing
> >> IDEs !  Imagine calling a function from the compiler to retrieve the
token
> >list
> >> for a module and easily syntax-highlighting the code from that.  Then
it's
> >a few
> >> steps away to analyzing the code trees and implementing some sort of code-completion or intellisense easily.  Documentation generators could
be
> >> written with ease!
> >>
> >> What does everyone think?  I can't find a reason *not* to go down this
> >path, but
> >> maybe others can...
> >>
> >> The library would probably want to have a plain C API that wraps the
> >internal
> >> C++ code for the most compatibility (especially with D programs).
> >>
> >> Regards,
> >> James Dunne
> >
> >
>
> That defeats the purpose of turning Walter's copy into a library.  Walter
always
> has the bleeding edge compiler.  If dmdfe is turned into a library, its maintainer will always have to play the never-ending ever-losing catch-up
game
> to update it to the current compiler, not to mention refactor it every
time a
> change happens so that it may still be a library.  No this doesn't sound
like a
> good idea, nor does it solve any of the problems I mentioned in the OP.
>
> Regards,
> James Dunne

James Dunne wrote:
> Why not make the compiler front-end into a dynamic library?
> 
> This would allow other tools to use the same implementation that the compiler
> itself uses for things like parsing, lexing, and analyzing code trees.  It would
> solve the problem of our development tools having to be consistently updated to
> support the latest and greatest additions to the D language.  Why duplicate
> effort and play the never-ending, ever-losing catch-up game?
> 
> Turning the compiler into a library will also have its advantages in writing
> IDEs !  Imagine calling a function from the compiler to retrieve the token list
> for a module and easily syntax-highlighting the code from that.  Then it's a few
> steps away to analyzing the code trees and implementing some sort of
> code-completion or intellisense easily.  Documentation generators could be
> written with ease!
> 
> What does everyone think?  I can't find a reason *not* to go down this path, but
> maybe others can...
> 
> The library would probably want to have a plain C API that wraps the internal
> C++ code for the most compatibility (especially with D programs).
> 
> Regards,
> James Dunne

D will be stable one day! I hope. :)

In article <devate$3095$1@digitaldaemon.com>, Charles says...
>
>> That defeats the purpose of turning Walter's copy into a library.  Walter
>always
>> has the bleeding edge compiler.  If dmdfe is turned into a library, its maintainer will always have to play the never-ending ever-losing catch-up
>game
>> to update it to the current compiler, not to mention refactor it every
>time a
>> change happens so that it may still be a library.  No this doesn't sound
>like a
>> good idea, nor does it solve any of the problems I mentioned in the OP.
>
>Yea , as much as Id like to see that also , I don't see it happening, was trying to offer a working alternative.
>
>While DMDFE is at .121 ( I'm actually trying to bring it up to .129 today ) , Ben has made it pretty easy to upgrade it ... and it _is_ a working front end to DMD capable of those things you talked about.  And the front-end is pretty complex, your going to have to get your hands dirty eventually :).
>
>Charlie
>
>

Perhaps it is possible (read: realistic) to fork dmdfe off into a library.  All you'd need is a well-defined, generic C API to create the classes and access the methods and data.  When I have some time, I'll check out dmdfe and see if I can at least get the lexer functionality into library form - without modifying any of the original C++ code.  Don't hold your breath though, I'm fairly busy as of late.

>"James Dunne" <james.jdunne@gmail.com> wrote in message news:deu610$20ke$1@digitaldaemon.com...
>> In article <detml2$1js2$1@digitaldaemon.com>, Charles says...
>> >
>> >There is dmdfe http://home.comcast.net/~benhinkle/dmdfe/ , a compilable front end that you can then make into a library if you want.
>> >
>> >"James Dunne" <james.jdunne@gmail.com> wrote in message news:deqajs$1q1u$1@digitaldaemon.com...
>> >> Why not make the compiler front-end into a dynamic library?
>> >>
>> >> This would allow other tools to use the same implementation that the
>> >compiler
>> >> itself uses for things like parsing, lexing, and analyzing code trees.
>It
>> >would
>> >> solve the problem of our development tools having to be consistently
>> >updated to
>> >> support the latest and greatest additions to the D language.  Why
>> >duplicate
>> >> effort and play the never-ending, ever-losing catch-up game?
>> >>
>> >> Turning the compiler into a library will also have its advantages in
>> >writing
>> >> IDEs !  Imagine calling a function from the compiler to retrieve the
>token
>> >list
>> >> for a module and easily syntax-highlighting the code from that.  Then
>it's
>> >a few
>> >> steps away to analyzing the code trees and implementing some sort of code-completion or intellisense easily.  Documentation generators could
>be
>> >> written with ease!
>> >>
>> >> What does everyone think?  I can't find a reason *not* to go down this
>> >path, but
>> >> maybe others can...
>> >>
>> >> The library would probably want to have a plain C API that wraps the
>> >internal
>> >> C++ code for the most compatibility (especially with D programs).
>> >>
>> >> Regards,
>> >> James Dunne
>> >
>> >
>>
>> That defeats the purpose of turning Walter's copy into a library.  Walter
>always
>> has the bleeding edge compiler.  If dmdfe is turned into a library, its maintainer will always have to play the never-ending ever-losing catch-up
>game
>> to update it to the current compiler, not to mention refactor it every
>time a
>> change happens so that it may still be a library.  No this doesn't sound
>like a
>> good idea, nor does it solve any of the problems I mentioned in the OP.
>>
>> Regards,
>> James Dunne
>
>

Regards,
James Dunne