View mode: basic / threaded / horizontal-split · Log in · Help
August 27, 2005
Make the front-end a C/C++ library?
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
August 27, 2005
Re: Make the front-end a C/C++ library?
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
August 29, 2005
Re: Make the front-end a C/C++ library?
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
August 29, 2005
Re: Make the front-end a C/C++ library?
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
August 29, 2005
Re: Make the front-end a C/C++ library?
> 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
August 29, 2005
Re: Make the front-end a C/C++ library?
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. :)
August 31, 2005
Re: Make the front-end a C/C++ library?
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
Top | Discussion index | About this forum | D home