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