www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Make the front-end a C/C++ library?

reply James Dunne <james.jdunne gmail.com> writes:
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
Aug 27 2005
next sibling parent Michael <Michael_member pathlink.com> writes:
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
Aug 27 2005
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
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
Aug 28 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
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
Aug 28 2005
parent reply "Charles" <noone nowhere.com> writes:
 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
Aug 29 2005
parent James Dunne <james.jdunne gmail.com> writes:
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
Aug 31 2005
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
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. :)
Aug 29 2005