www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DDMD and such.

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I know, this has been discussed earlier, but i don't quite understand
the real reason why isn't DMD's front-end being written in D.
Existing DDMD is pointless (and i think abandoned), because it's just
a plain rewrite with the same C-style constructs and completely
rewriting it to be a correct D code would mean being unable to get the
bug-fixes on DMD.
I remember, that Walter said about the problems with compatibility
with the back-end, that would arise.
But isn't D supposed to be binary compatible with C?
AFAIK the only extra thing to be done would be to provide a C facade
around the D front-end, that would be given to the back-end.
Why not?
Sep 28 2011
next sibling parent reply Trass3r <un known.com> writes:
Am 28.09.2011, 15:09 Uhr, schrieb Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com>:


 I know, this has been discussed earlier, but i don't quite understand
 the real reason why isn't DMD's front-end being written in D.
 Existing DDMD is pointless (and i think abandoned), because it's just
 a plain rewrite with the same C-style constructs and completely
 rewriting it to be a correct D code would mean being unable to get the
 bug-fixes on DMD.


Yep, it's pointless cause it inherits all of dmd's quirks.
Rewriting most of ddmd to overcome dmd's design flaws would be overkill.
Also keeping in sync with dmd is hard since there is no way of  
auto-applying patches. Everything has to be done by hand and believe me,  
it's not fun.

I think dmd should keep going its way and provide a base..
(remember that it also provides a base for gdc/ldc. If dmd switched to D  
there would also be no updates for LDC and GDC anymore)

..for a future new frontend written from scratch in D with a proper design  
that isn't restricted to a single application (i.e. compiler),
similar to Clang but properly implemented. Clang drifted away from its  
goals, especially the "easily hackable" one.

Unfortunately there is no such project yet.
Dil is quite nice, but it's D1 and GPL.
Sep 28 2011
next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I saw many problems and bugs in DMD is due to it's C nature and would
be gone, be it written on D.
But since DMD can't switch to D at least because of LDC and GDC, the
only way to name a D-written D front-end is to work on a parallel
project.
And having 2 parallel projects is absolutely pointless, because
neither one will have enough manpower to quickly develop it and
because there will be 2 unstable compilers instead of a single stable
one.
I guess Walter and co. could switch to D front-end only after all bugs
of D2 are fixed and D2 reaches it's end point, beyond which it won't
get enhanced further (probably this would be the start of a new D
major version).
So, I hope D3 will start developing in D itself (assuming, that D3
will ever come along, since no-one seems to want it to happen).

On Wed, Sep 28, 2011 at 5:48 PM, Trass3r <un known.com> wrote:

 Am 28.09.2011, 15:09 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I know, this has been discussed earlier, but i don't quite understand
 the real reason why isn't DMD's front-end being written in D.
 Existing DDMD is pointless (and i think abandoned), because it's just
 a plain rewrite with the same C-style constructs and completely
 rewriting it to be a correct D code would mean being unable to get the
 bug-fixes on DMD.


 Yep, it's pointless cause it inherits all of dmd's quirks.
 Rewriting most of ddmd to overcome dmd's design flaws would be overkill.
 Also keeping in sync with dmd is hard since there is no way of auto-applying
 patches. Everything has to be done by hand and believe me, it's not fun.

 I think dmd should keep going its way and provide a base..
 (remember that it also provides a base for gdc/ldc. If dmd switched to D
 there would also be no updates for LDC and GDC anymore)

 ..for a future new frontend written from scratch in D with a proper design
 that isn't restricted to a single application (i.e. compiler),
 similar to Clang but properly implemented. Clang drifted away from its
 goals, especially the "easily hackable" one.

 Unfortunately there is no such project yet.
 Dil is quite nice, but it's D1 and GPL.
Sep 28 2011
parent reply Trass3r <un known.com> writes:
 And having 2 parallel projects is absolutely pointless, because
 neither one will have enough manpower to quickly develop it and
 because there will be 2 unstable compilers instead of a single stable
 one.


Well a new frontend would need to be a real community project anyway.
It's ok that Walter checks every patch cause experience shows there are  
several ways to fix a bug.
But that just doesn't scale. Pull requests are piling up already.
We'd need more people that have proven to be valuable contributors like  
Don to get direct access.

You are right that another compiler is pointless if it isn't as good as  
dmd cause nobody would use it.
See dil, it has a complete lexer and parser, 31k LOC, but you can't use it  
and it's rotting AFAIK.
It's only good for creating documentation and even that isn't perfect  
since it's missing semantic analysis (i.e. auto isn't resolved etc).


But this example shows the path:
Imho a new frontend would need to focus on non-compiler applications  
first, such as
- auto-completion etc. for IDEs
- rewriting tools
(- doc generation)

cause these don't require a full-blown semantic analysis and codegen.
And as soon as it matures it can also be used as a compiler.



 I guess Walter and co. could switch to D front-end only after all bugs
 of D2 are fixed and D2 reaches it's end point, beyond which it won't
 get enhanced further (probably this would be the start of a new D
 major version).
 So, I hope D3 will start developing in D itself (assuming, that D3
 will ever come along, since no-one seems to want it to happen).


Yeah probably, but there won't be any D3 anytime soon cause it will take  
long to properly implement D2.
Sep 28 2011
next sibling parent reply Trass3r <un known.com> writes:
 But this example shows the path:
 Imho a new frontend would need to focus on non-compiler applications  
 first, such as
 - auto-completion etc. for IDEs
 - rewriting tools
 (- doc generation)

 cause these don't require a full-blown semantic analysis and codegen.


I think this strategy would also enforce a proper design since  
requirements are much firmer especially in the IDE context,
e.g. performance, memory usage, no stdout, exception safety, ...
Sep 28 2011
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Yes. Indeed the presence of more then one (unlimited amount) of
back-ends would require the front-end to be very carefully designed
and bug-free. And this will force the front-end to be a separate tool,
which will generate a standardized semantically tagged AST, which in
turn can be used by any back-end (DMC, GCC, LLVM, maybe even VC++ ...)
to generate code or any development tool (automatic build system,
editors, automatic code analyzers, ...).
I think having an official reference front-end like that is much
better, then having an official reference compiler, since it gives a
lot more flexibility, while it doesn't complicate anything.

But then the age-old human resource problem arises. Will D community
work on an official reference front-end while DMD is alive and full of
bugs? I think not. And despite the fact, that I'd love to dedicate my
time to make a good front-end, 1 developer is not nearly enough for
that.

It seems, like all the D's remarkable parse-ability is currently being
wasted, since DMD's buggy front-end is indeed the ONLY existing D
parser (i don't take into account the non-working ones, like Dil).
Pity...

On Wed, Sep 28, 2011 at 6:27 PM, Trass3r <un known.com> wrote:

 But this example shows the path:
 Imho a new frontend would need to focus on non-compiler applications
 first, such as
 - auto-completion etc. for IDEs
 - rewriting tools
 (- doc generation)

 cause these don't require a full-blown semantic analysis and codegen.


 I think this strategy would also enforce a proper design since requirements
 are much firmer especially in the IDE context,
 e.g. performance, memory usage, no stdout, exception safety, ...
Sep 28 2011
parent reply Trass3r <un known.com> writes:
 Yes. Indeed the presence of more then one (unlimited amount) of
 back-ends would require the front-end to be very carefully designed
 and bug-free. And this will force the front-end to be a separate tool,
 which will generate a standardized semantically tagged AST, which in
 turn can be used by any back-end (DMC, GCC, LLVM, maybe even VC++ ...)
 to generate code or any development tool (automatic build system,
 editors, automatic code analyzers, ...).


It's not only about frontend/backend separation.
The frontend needs to be fully modular. Some applications might not even  
wish to build up a full AST (like TCC and GCC) while others like  
refactoring tools need highly detailed information about the original  
source code.
So for example the parser must not directly build an AST, but rather take  
an interface with ActOnForeachStmt like methods.



 I think having an official reference front-end like that is much
 better, then having an official reference compiler, since it gives a
 lot more flexibility, while it doesn't complicate anything.


Yep, reusability.


 It seems, like all the D's remarkable parse-ability is currently being
 wasted, since DMD's buggy front-end is indeed the ONLY existing D
 parser (i don't take into account the non-working ones, like Dil).


What about dil's parser isn't working?
I thought it was pretty complete.
Sep 28 2011
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
On Wed, Sep 28, 2011 at 7:22 PM, Trass3r <un known.com> wrote:

 It's not only about frontend/backend separation.
 The frontend needs to be fully modular. Some applications might not even wish
to build up a full AST (like TCC and GCC) while others like refactoring tools
need highly detailed information about the original source code.
 So for example the parser must not directly build an AST, but rather take an
interface with ActOnForeachStmt like methods.


Yes. I agree. Hm... What if we make a highly modular D-based front-end
like that and provide a DMD-front-end adapter for it?
That wouldn't break anything. DMC, GCC and LLVM would still get the
required data, taken from a front-end with the same interface, so
neither of three compilers would notice the change.
How about that? We could take Dil's parser and work on it as an
alternative to starting from scratch.

On Wed, Sep 28, 2011 at 7:22 PM, Trass3r <un known.com> wrote:

 What about dil's parser isn't working?
 I thought it was pretty complete.


It doesn't do semantic analysis. Without semantic analysis, it's
useless beyond ddoc.
Sep 28 2011
parent Trass3r <un known.com> writes:
 Yes. I agree. Hm... What if we make a highly modular D-based front-end
 like that and provide a DMD-front-end adapter for it?
 That wouldn't break anything. DMC, GCC and LLVM would still get the
 required data, taken from a front-end with the same interface, so
 neither of three compilers would notice the change.


Pretty impossible I think.
They are written in C++ and there's no real such thing as an interface.  
They access the AST nodes directly.
Also IIRC they modify the nodes to contain specific information for their  
backend.


 How about that? We could take Dil's parser and work on it as an
 alternative to starting from scratch.


Yeah but as I said, it's D1/Tango and GPL.


 What about dil's parser isn't working?
 I thought it was pretty complete.


 It doesn't do semantic analysis. Without semantic analysis, it's
 useless beyond ddoc.


Agreed, but semantic analysis != parser :)
Sep 28 2011
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
 Yeah probably, but there won't be any D3 anytime soon cause it will take
 long to properly implement D2.


That's the whole point. It's a closed loop:
* New front-end isn't being developed because the existing one needs attention.
* Existing one needs attention because it has numerous design flaws.
* It has numerous design flaws because a new front-end isn't being developed.
* New front-end isn't being developed because the existing one needs attention.
* ...

And so the progress crawls slowly toward the resolution of all
problems of current front-end through a long and painful path, full of
bugs and instability.
Sep 28 2011
prev sibling next sibling parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I agree, that rewriting the language is not a good idea until the
current version is fully studied, so i don't want D3 either. D2 is
good enough for now.
But I don't have D2 because most of what makes it unique isn't
implemented or is buggy. And i still won't have it for a long long
time (I really want classes in CTFE, for example).

On Wed, Sep 28, 2011 at 6:42 PM, Gor Gyolchanyan
<gor.f.gyolchanyan gmail.com> wrote:

 Yeah probably, but there won't be any D3 anytime soon cause it will take
 long to properly implement D2.


 That's the whole point. It's a closed loop:
 * New front-end isn't being developed because the existing one needs attention.
 * Existing one needs attention because it has numerous design flaws.
 * It has numerous design flaws because a new front-end isn't being developed.
 * New front-end isn't being developed because the existing one needs attention.
 * ...

 And so the progress crawls slowly toward the resolution of all
 problems of current front-end through a long and painful path, full of
 bugs and instability.
Sep 28 2011
next sibling parent reply Trass3r <un known.com> writes:
 But I don't have D2 because most of what makes it unique isn't
 implemented or is buggy. And i still won't have it for a long long
 time (I really want classes in CTFE, for example).


I personally use D2 very conservatively, more like a D1 + a few missing  
things like struct ctors/dtors, compile-time reflection, const for  
parameters/methods and alias this (the latter not excessively though).
Sep 28 2011
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Using a multi-paradigm programming language is better, then using two
languages with two separate paradigms, because the mixture of more
then one paradigm in a single language is itself a new paradigm.
The interoperability of two paradigms, implemented in a language
enabled a whole new way of getting things done.
D supports much more programming paradigms, then any other language i
know. The combination of all those paradigms enabled D programmers to
do things, that is impossible to do in any other language.
Your approach to D2 as a slightly enhanced D1 kills that advantage of
D. Although i can understand why you chose to do that (and i agree
with your choice given the circumstances).
I just don't want to invest lots of time and effort in code, that does
not use language features, that are about to be implemented (although
the "about to be" can range from days to years).
The point is: the language can, but the compiler can't.
It turns out, that your approach uses DMD programming language, not D
programming language.

On Wed, Sep 28, 2011 at 7:09 PM, Trass3r <un known.com> wrote:

 But I don't have D2 because most of what makes it unique isn't
 implemented or is buggy. And i still won't have it for a long long
 time (I really want classes in CTFE, for example).


 I personally use D2 very conservatively, more like a D1 + a few missing
 things like struct ctors/dtors, compile-time reflection, const for
 parameters/methods and alias this (the latter not excessively though).
Sep 28 2011
parent Trass3r <un known.com> writes:
Am 28.09.2011, 17:23 Uhr, schrieb Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com>:


 D supports much more programming paradigms, then any other language i
 know. The combination of all those paradigms enabled D programmers to
 do things, that is impossible to do in any other language.
 Your approach to D2 as a slightly enhanced D1 kills that advantage of
 D. Although i can understand why you chose to do that (and i agree
 with your choice given the circumstances).
 I just don't want to invest lots of time and effort in code, that does
 not use language features, that are about to be implemented (although
 the "about to be" can range from days to years).


Well it's not like I give up anything.
Most of D's (esp. optimization) potential isn't used yet anyways.
So as a very basic example declaring a function pure doesn't change much,  
at least with dmd (llvm has interesting IR attributes like readonly and  
nocapture that look suspiciously like pure and scope but I don't know if  
LDC uses them).
Sep 28 2011
prev sibling parent Don <nospam nospam.com> writes:
On 28.09.2011 16:45, Gor Gyolchanyan wrote:

 I agree, that rewriting the language is not a good idea until the
 current version is fully studied, so i don't want D3 either. D2 is
 good enough for now.
 But I don't have D2 because most of what makes it unique isn't
 implemented or is buggy. And i still won't have it for a long long
 time (I really want classes in CTFE, for example).


Not so long. Classes in CTFE is about two releases away.
Sep 29 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Trass3r Wrote:


 But this example shows the path:
 Imho a new frontend would need to focus on non-compiler applications  
 first, such as
 - auto-completion etc. for IDEs
 - rewriting tools
 (- doc generation)
 
 cause these don't require a full-blown semantic analysis and codegen.
 And as soon as it matures it can also be used as a compiler.


Will it be able into CTFE and string mixins without semantic analysis?
Sep 28 2011
parent Trass3r <un known.com> writes:
 Will it be able into CTFE and string mixins without semantic analysis?


No. I only said you don't need a completely implemented one.
Sep 28 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Trass3r" <un known.com> wrote in message news:op.v2itzrb73ncmek enigma...

 Am 28.09.2011, 15:09 Uhr, schrieb Gor Gyolchanyan 
 <gor.f.gyolchanyan gmail.com>:


 I know, this has been discussed earlier, but i don't quite understand
 the real reason why isn't DMD's front-end being written in D.
 Existing DDMD is pointless (and i think abandoned), because it's just
 a plain rewrite with the same C-style constructs and completely
 rewriting it to be a correct D code would mean being unable to get the
 bug-fixes on DMD.


 Yep, it's pointless cause it inherits all of dmd's quirks.
 Rewriting most of ddmd to overcome dmd's design flaws would be overkill.
 Also keeping in sync with dmd is hard since there is no way of 
 auto-applying patches. Everything has to be done by hand and believe me, 
 it's not fun.

 I think dmd should keep going its way and provide a base..
 (remember that it also provides a base for gdc/ldc. If dmd switched to D 
 there would also be no updates for LDC and GDC anymore)

 ..for a future new frontend written from scratch in D with a proper design 
 that isn't restricted to a single application (i.e. compiler),
 similar to Clang but properly implemented. Clang drifted away from its 
 goals, especially the "easily hackable" one.

 Unfortunately there is no such project yet.
 Dil is quite nice, but it's D1 and GPL.


I think this approach I mentioned before could work:

http://www.mail-archive.com/digitalmars-d puremagic.com/msg64350.html
Sep 28 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-09-28 15:48, Trass3r wrote:

 Am 28.09.2011, 15:09 Uhr, schrieb Gor Gyolchanyan
 <gor.f.gyolchanyan gmail.com>:


 I know, this has been discussed earlier, but i don't quite understand
 the real reason why isn't DMD's front-end being written in D.
 Existing DDMD is pointless (and i think abandoned), because it's just
 a plain rewrite with the same C-style constructs and completely
 rewriting it to be a correct D code would mean being unable to get the
 bug-fixes on DMD.


 Yep, it's pointless cause it inherits all of dmd's quirks.
 Rewriting most of ddmd to overcome dmd's design flaws would be overkill.
 Also keeping in sync with dmd is hard since there is no way of
 auto-applying patches. Everything has to be done by hand and believe me,
 it's not fun.

 I think dmd should keep going its way and provide a base..
 (remember that it also provides a base for gdc/ldc. If dmd switched to D
 there would also be no updates for LDC and GDC anymore)


Why wouldn't it? LDC and GDC can use the frontend written in D.


 ..for a future new frontend written from scratch in D with a proper
 design that isn't restricted to a single application (i.e. compiler),
 similar to Clang but properly implemented. Clang drifted away from its
 goals, especially the "easily hackable" one.


I agree.


 Unfortunately there is no such project yet.
 Dil is quite nice, but it's D1 and GPL.


I think someone is slowly porting the lexer from DMD to D, which will be 
included in Phobos. There where discussions about this some time ago.

I think that the right approach would be to have a modular frontend 
written in D that can be used as a library, think Clang. Then DMD could 
use this frontend and connect it with the DMC backend.

To get this frontend I think the DMD frontend needs to be ported to D 
without much modification in the first step. DMD would then use the D 
version of the frontend. When the complete frontend is ported and used 
by DMD, then we could start refactoring the frontend to make it more 
modular.

I think this is the most realistic approach. I don't think Walter would 
just drop the DMD frontend and start with a new one, or use some other 
frontend developed by someone else.

-- 
/Jacob Carlborg
Sep 28 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:j5vu43$580$1 digitalmars.com...

 I think that the right approach would be to have a modular frontend 
 written in D that can be used as a library, think Clang. Then DMD could 
 use this frontend and connect it with the DMC backend.

 To get this frontend I think the DMD frontend needs to be ported to D 
 without much modification in the first step. DMD would then use the D 
 version of the frontend. When the complete frontend is ported and used by 
 DMD, then we could start refactoring the frontend to make it more modular.

 I think this is the most realistic approach. I don't think Walter would 
 just drop the DMD frontend and start with a new one, or use some other 
 frontend developed by someone else.


I agree, but I think it might be best to start by creating D bindings to the 
C++-based frontend. That way the frontend could be ported to D (without much 
modification) piece-by-piece. Kind of like the way Walter's porting Optlink 
from Asm to C.
Sep 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-09-28 22:52, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:j5vu43$580$1 digitalmars.com...

 I think that the right approach would be to have a modular frontend
 written in D that can be used as a library, think Clang. Then DMD could
 use this frontend and connect it with the DMC backend.

 To get this frontend I think the DMD frontend needs to be ported to D
 without much modification in the first step. DMD would then use the D
 version of the frontend. When the complete frontend is ported and used by
 DMD, then we could start refactoring the frontend to make it more modular.

 I think this is the most realistic approach. I don't think Walter would
 just drop the DMD frontend and start with a new one, or use some other
 frontend developed by someone else.


 I agree, but I think it might be best to start by creating D bindings to the
 C++-based frontend. That way the frontend could be ported to D (without much
 modification) piece-by-piece. Kind of like the way Walter's porting Optlink
 from Asm to C.


I guess starting with that would be even better. The question is, how 
would that be done? Using D's capabilities in connecting with C++ or a C 
interface?

-- 
/Jacob Carlborg
Sep 28 2011
prev sibling parent reply Trass3r <un known.com> writes:
 I think dmd should keep going its way and provide a base..
 (remember that it also provides a base for gdc/ldc. If dmd switched to D
 there would also be no updates for LDC and GDC anymore)


 Why wouldn't it? LDC and GDC can use the frontend written in D.


No, they are totally based on dmd. Written in C++, directly accessing the  
AST nodes (i.e. no "interface") and even modifying the nodes to contain  
additional info.


 To get this frontend I think the DMD frontend needs to be ported to D  
 without much modification in the first step. DMD would then use the D  
 version of the frontend. When the complete frontend is ported and used  
 by DMD, then we could start refactoring the frontend to make it more  
 modular.

 I think this is the most realistic approach. I don't think Walter would  
 just drop the DMD frontend and start with a new one, or use some other  
 frontend developed by someone else.


And he also won't drop dmd even for a 1-to-1 port ;)
Sep 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-09-29 04:34, Trass3r wrote:

 I think dmd should keep going its way and provide a base..
 (remember that it also provides a base for gdc/ldc. If dmd switched to D
 there would also be no updates for LDC and GDC anymore)


 Why wouldn't it? LDC and GDC can use the frontend written in D.


 No, they are totally based on dmd. Written in C++, directly accessing
 the AST nodes (i.e. no "interface") and even modifying the nodes to
 contain additional info.


If DMD can use a fronend written in D and a backend in C++ so could GDC 
and LDC.


 To get this frontend I think the DMD frontend needs to be ported to D
 without much modification in the first step. DMD would then use the D
 version of the frontend. When the complete frontend is ported and used
 by DMD, then we could start refactoring the frontend to make it more
 modular.

 I think this is the most realistic approach. I don't think Walter
 would just drop the DMD frontend and start with a new one, or use some
 other frontend developed by someone else.


 And he also won't drop dmd even for a 1-to-1 port ;)


I really hope you're wrong. If it IS a 1-to-1 port it would be DMD and 
he wouldn't drop DMD, it would just be written in D instead of C++.

-- 
/Jacob Carlborg
Sep 28 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> wrote in message 
news:mailman.246.1317215375.26225.digitalmars-d puremagic.com...

I know, this has been discussed earlier, but i don't quite understand
 the real reason why isn't DMD's front-end being written in D.
 Existing DDMD is pointless (and i think abandoned), because it's just
 a plain rewrite with the same C-style constructs and completely
 rewriting it to be a correct D code would mean being unable to get the
 bug-fixes on DMD.
 I remember, that Walter said about the problems with compatibility
 with the back-end, that would arise.
 But isn't D supposed to be binary compatible with C?
 AFAIK the only extra thing to be done would be to provide a C facade
 around the D front-end, that would be given to the back-end.
 Why not?


FWIW, There's isn't a very strong separation between the frontend and 
backend. A lot of the backend functions are in the same AST classes that 
also have a lot of front-end stuff. I could be wrong, but I'm guessing that 
could be difficult to have classes that are partially implemented in C++ and 
partially in D.

And since people seem to be getting by with the C++-based source, I'm sure 
there's lots of more important priorities.
Sep 28 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:j5vf1k$2c29$1 digitalmars.com...

 "Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> wrote in message 
 news:mailman.246.1317215375.26225.digitalmars-d puremagic.com...

I know, this has been discussed earlier, but i don't quite understand
 the real reason why isn't DMD's front-end being written in D.
 Existing DDMD is pointless (and i think abandoned), because it's just
 a plain rewrite with the same C-style constructs and completely
 rewriting it to be a correct D code would mean being unable to get the
 bug-fixes on DMD.
 I remember, that Walter said about the problems with compatibility
 with the back-end, that would arise.
 But isn't D supposed to be binary compatible with C?
 AFAIK the only extra thing to be done would be to provide a C facade
 around the D front-end, that would be given to the back-end.
 Why not?


 FWIW, There's isn't a very strong separation between the frontend and 
 backend. A lot of the backend functions are in the same AST classes that 
 also have a lot of front-end stuff. I could be wrong, but I'm guessing 
 that could be difficult to have classes that are partially implemented in 
 C++ and partially in D.


Although that said, DDMD *did* already solve that problem, so maybe it 
wouldn't be too bad after all?


 And since people seem to be getting by with the C++-based source, I'm sure 
 there's lots of more important priorities.
Sep 28 2011
parent reply Trass3r <un known.com> writes:
 FWIW, There's isn't a very strong separation between the frontend and
 backend. A lot of the backend functions are in the same AST classes that
 also have a lot of front-end stuff. I could be wrong, but I'm guessing
 that could be difficult to have classes that are partially implemented  
 in C++ and partially in D.


 Although that said, DDMD *did* already solve that problem, so maybe it
 wouldn't be too bad after all?


The backend integration in ddmd is rather hackish. It is somehow compiled  
as a library and then called from ddmd. Moreover there are dependencies  
 from the backend back to the frontend that complicate the situation. It  
was rather scary when I last looked at it.
Sep 28 2011
next sibling parent reply Trass3r <un known.com> writes:
 Moreover there are dependencies from the backend back to the frontend


I meant the other way around.
Sep 28 2011
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I see. Somehow I'm not surprised. It tends to happen to C++ code I had
opportunity to read so far. :-)

On Wed, Sep 28, 2011 at 8:21 PM, Trass3r <un known.com> wrote:

 Moreover there are dependencies from the backend back to the frontend


 I meant the other way around.
Sep 28 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-09-28 18:19, Trass3r wrote:

 FWIW, There's isn't a very strong separation between the frontend and
 backend. A lot of the backend functions are in the same AST classes that
 also have a lot of front-end stuff. I could be wrong, but I'm guessing
 that could be difficult to have classes that are partially
 implemented in C++ and partially in D.


 Although that said, DDMD *did* already solve that problem, so maybe it
 wouldn't be too bad after all?


 The backend integration in ddmd is rather hackish. It is somehow
 compiled as a library and then called from ddmd. Moreover there are
 dependencies from the backend back to the frontend that complicate the
 situation. It was rather scary when I last looked at it.


Yeah, it's not pretty. There where also a lot of D/C++ integration bugs 
that needed to be fixed to get everything working. BTW, are all those 
bugs fixed?

-- 
/Jacob Carlborg
Sep 28 2011
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 28, 2011 07:45 Gor Gyolchanyan wrote:

 I agree, that rewriting the language is not a good idea until the
 current version is fully studied, so i don't want D3 either. D2 is
 good enough for now.
 But I don't have D2 because most of what makes it unique isn't
 implemented or is buggy. And i still won't have it for a long long
 time (I really want classes in CTFE, for example).


Having a D compiler for D would be cool, but really, does it matter? At least, 
to the average programmer? The average programmer wants a compiler that works. 
Fixing dmd's bugs gets you that. That's what's being done. Rewriting dmd in D 
doesn't help with that at all. In fact it makes it worse, because it's 
inevitable that new bugs will be introduced.

In the long run, it would be nice to have a compiler in D (maybe even the 
primary compiler), and maybe such a compiler could be more performant thanks 
to slicing and the like. But until D2 is fully stable, that just seems like 
wasted effort. There are far more important things for getting D2 fully 
usable. The operative word is "nice." It would be _nice_ if we had a fully 
working D compiler in D, but it's far from necessary and really doesn't gain 
us much at this point in time.

I honestly don't understand why having a D compiler in written in D is so 
important to some people. What we need is a solid compiler. The language that 
it's in doesn't matter all that much IMHO. Yes, it's a good sign for D if it 
can have a fully functional, performant compiler written in D (especially if 
it's _more_ performant than a comparable compiler written in C++), but what 
matters is being able to write your own code in D, not whether the tools 
you're using were written in any particular language.

However, regardless of why you might want another D compiler with a new 
frontend, I think that it would make a _lot_ of sense to wait until D2's spec 
has completely stabilized (it's fairly stable now but not completely stable), 
and dmd is more or less bug-free (obviously not completely bug-free, but on 
the level typically expected of a compiler). That would severely reduce how 
much rewriting you would have to do as D and dmd change, and the problem would 
become much more tractable.

- Jonathan M Davis
Sep 28 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-09-28 19:14, Jonathan M Davis wrote:

 On Wednesday, September 28, 2011 07:45 Gor Gyolchanyan wrote:

 I agree, that rewriting the language is not a good idea until the
 current version is fully studied, so i don't want D3 either. D2 is
 good enough for now.
 But I don't have D2 because most of what makes it unique isn't
 implemented or is buggy. And i still won't have it for a long long
 time (I really want classes in CTFE, for example).


 Having a D compiler for D would be cool, but really, does it matter? At least,
 to the average programmer? The average programmer wants a compiler that works.
 Fixing dmd's bugs gets you that. That's what's being done. Rewriting dmd in D
 doesn't help with that at all. In fact it makes it worse, because it's
 inevitable that new bugs will be introduced.

 In the long run, it would be nice to have a compiler in D (maybe even the
 primary compiler), and maybe such a compiler could be more performant thanks
 to slicing and the like. But until D2 is fully stable, that just seems like
 wasted effort. There are far more important things for getting D2 fully
 usable. The operative word is "nice." It would be _nice_ if we had a fully
 working D compiler in D, but it's far from necessary and really doesn't gain
 us much at this point in time.

 I honestly don't understand why having a D compiler in written in D is so
 important to some people. What we need is a solid compiler. The language that
 it's in doesn't matter all that much IMHO. Yes, it's a good sign for D if it
 can have a fully functional, performant compiler written in D (especially if
 it's _more_ performant than a comparable compiler written in C++), but what
 matters is being able to write your own code in D, not whether the tools
 you're using were written in any particular language.

 However, regardless of why you might want another D compiler with a new
 frontend, I think that it would make a _lot_ of sense to wait until D2's spec
 has completely stabilized (it's fairly stable now but not completely stable),
 and dmd is more or less bug-free (obviously not completely bug-free, but on
 the level typically expected of a compiler). That would severely reduce how
 much rewriting you would have to do as D and dmd change, and the problem would
 become much more tractable.

 - Jonathan M Davis


Yes it does matter. The most important thing isn't what language the 
compiler is written in, but let me but it this way. There are some much 
else, beside from a compiler, that a frontend can be used for:

IDE integration:

* Syntax highlighting
* Code completion
* Showing syntax and semantic errors
* Refactoring
* Outline views
* DDoc views

Other:

* Debugger
* Source-to-source compiler

Example of how it's working with GCC (or has been working). There's a 
complete frontend in the compiler. There's another half-working 
frontend/expression parser in the debugger. There's third half-working 
frontend in some IDE. That's just crazy.

What is important is to have a modular frontend that can be used as a 
library. Having something like what Clang is for C/C++/Objective-C, but 
for D.

We all want to write our programs and tools in D, that's why we're here 
right. Now, what if it happens that your tool needs some kind of 
functionality that can be found in the frontend. With a modular frontend 
that can be used like a library you just use the frontend as every other 
library and there's nothing special about it. To be able to use the 
library with D it would be a lot easier if it's written in D, not 
necessary, but a lot easier.

So in the end, the language a compiler/frontend is written in is quite 
important.

-- 
/Jacob Carlborg
Sep 28 2011
prev sibling parent reply travert phare.normalesup.org (Christophe) writes:
"Jonathan M Davis" , dans le message (digitalmars.D:145639), a écrit :

 I honestly don't understand why having a D compiler in written in D is so 
 important to some people. What we need is a solid compiler. The language that 
 it's in doesn't matter all that much IMHO. Yes, it's a good sign for D if it 
 can have a fully functional, performant compiler written in D (especially if 
 it's _more_ performant than a comparable compiler written in C++), but what 
 matters is being able to write your own code in D, not whether the tools 
 you're using were written in any particular language.


Having a compiler written in D may help people from the community to 
try and understand the compiler's code written in their favorite 
langage, so there may be more people invested here. You have much more 
volunteers to write D code for the library for example.

However, as long as the langage (and phobos?) is not stable, it does not 
seems to be a good idea to write the compiler in D. We want the compiler 
to be safe and stable at first.
Sep 29 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Right. And if the compiler is written in D, it's much more readable
and maintainable and it will gain much more volunteer manpower, since
it's so easy to work on.

On Thu, Sep 29, 2011 at 12:21 PM, Christophe
<travert phare.normalesup.org> wrote:

 "Jonathan M Davis" , dans le message (digitalmars.D:145639), a =E9crit=A0=


:

 I honestly don't understand why having a D compiler in written in D is s=




o

 important to some people. What we need is a solid compiler. The language=




 that

 it's in doesn't matter all that much IMHO. Yes, it's a good sign for D i=




f it

 can have a fully functional, performant compiler written in D (especiall=




y if

 it's _more_ performant than a comparable compiler written in C++), but w=




hat

 matters is being able to write your own code in D, not whether the tools
 you're using were written in any particular language.


 Having a compiler written in D may help people from the community to
 try and understand the compiler's code written in their favorite
 langage, so there may be more people invested here. You have much more
 volunteers to write D code for the library for example.

 However, as long as the langage (and phobos?) is not stable, it does not
 seems to be a good idea to write the compiler in D. We want the compiler
 to be safe and stable at first.
Sep 29 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 29, 2011 13:35:03 Gor Gyolchanyan wrote:

 Right. And if the compiler is written in D, it's much more readable
 and maintainable and it will gain much more volunteer manpower, since
 it's so easy to work on.


While the compiler probably would be easier to work on if it were written in 
D, I honestly don't think that it would be enough of an improvement to really 
make that much of a difference in volunteer manpower, unless we were dealing 
with a bunch of potential volunteers who knew D but not C++. The issue with 
working on the compiler is understanding what the code is trying to do and how 
it works, not the fact that it's written C++ rather than D.

The primary advantage is in having a lexer and parser that any program can 
then use, because then it makes it much easier to create tools which can 
process D code. The compiler itself isn't really going to gain much by being 
in D.

- Jonathan m Davis
Sep 29 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/29/2011 11:44 AM, Jonathan M Davis wrote:

 On Thursday, September 29, 2011 13:35:03 Gor Gyolchanyan wrote:

 Right. And if the compiler is written in D, it's much more readable
 and maintainable and it will gain much more volunteer manpower, since
 it's so easy to work on.


 While the compiler probably would be easier to work on if it were written in
 D, I honestly don't think that it would be enough of an improvement to really
 make that much of a difference in volunteer manpower, unless we were dealing
 with a bunch of potential volunteers who knew D but not C++. The issue with
 working on the compiler is understanding what the code is trying to do and how
 it works, not the fact that it's written C++ rather than D.


D code is usually more understandable. But I agree that a 1 to 1 port of 
DMD is quite pointless.


 The primary advantage is in having a lexer and parser that any program can
 then use, because then it makes it much easier to create tools which can
 process D code. The compiler itself isn't really going to gain much by being
 in D.


Writing a D parser from scratch in D is quite easy. I think we should 
drop the "guaranteed equivalent to DMDs parser because it is a direct 
port of it" requirement.
Sep 29 2011
prev sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I agree. The main point is, that the compiler is a mess. Translating
it to D was a kind of "clean the code up and translate in to a
better-looking language while you're at it.".
If the C++ code is made more modular and clean, it would already be a
good progress.

On Thu, Sep 29, 2011 at 1:44 PM, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Thursday, September 29, 2011 13:35:03 Gor Gyolchanyan wrote:

 Right. And if the compiler is written in D, it's much more readable
 and maintainable and it will gain much more volunteer manpower, since
 it's so easy to work on.


 While the compiler probably would be easier to work on if it were written in
 D, I honestly don't think that it would be enough of an improvement to really
 make that much of a difference in volunteer manpower, unless we were dealing
 with a bunch of potential volunteers who knew D but not C++. The issue with
 working on the compiler is understanding what the code is trying to do and how
 it works, not the fact that it's written C++ rather than D.

 The primary advantage is in having a lexer and parser that any program can
 then use, because then it makes it much easier to create tools which can
 process D code. The compiler itself isn't really going to gain much by being
 in D.

 - Jonathan m Davis
Sep 29 2011
prev sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Good point. The reason to have D compiler written in D is that D code
is far less error-prone, then C++, while giving the tools for very
high-level modeling of the problem it solves (which DMD doesn't seem
to use).
Well, seems like all the "exciting stuff", like a new major version
and a new front-end are left for serious consideration only when the
current one is fully developed.

On Wed, Sep 28, 2011 at 9:14 PM, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Wednesday, September 28, 2011 07:45 Gor Gyolchanyan wrote:

 I agree, that rewriting the language is not a good idea until the
 current version is fully studied, so i don't want D3 either. D2 is
 good enough for now.
 But I don't have D2 because most of what makes it unique isn't
 implemented or is buggy. And i still won't have it for a long long
 time (I really want classes in CTFE, for example).


 Having a D compiler for D would be cool, but really, does it matter? At least,
 to the average programmer? The average programmer wants a compiler that works.
 Fixing dmd's bugs gets you that. That's what's being done. Rewriting dmd in D
 doesn't help with that at all. In fact it makes it worse, because it's
 inevitable that new bugs will be introduced.

 In the long run, it would be nice to have a compiler in D (maybe even the
 primary compiler), and maybe such a compiler could be more performant thanks
 to slicing and the like. But until D2 is fully stable, that just seems like
 wasted effort. There are far more important things for getting D2 fully
 usable. The operative word is "nice." It would be _nice_ if we had a fully
 working D compiler in D, but it's far from necessary and really doesn't gain
 us much at this point in time.

 I honestly don't understand why having a D compiler in written in D is so
 important to some people. What we need is a solid compiler. The language that
 it's in doesn't matter all that much IMHO. Yes, it's a good sign for D if it
 can have a fully functional, performant compiler written in D (especially if
 it's _more_ performant than a comparable compiler written in C++), but what
 matters is being able to write your own code in D, not whether the tools
 you're using were written in any particular language.

 However, regardless of why you might want another D compiler with a new
 frontend, I think that it would make a _lot_ of sense to wait until D2's spec
 has completely stabilized (it's fairly stable now but not completely stable),
 and dmd is more or less bug-free (obviously not completely bug-free, but on
 the level typically expected of a compiler). That would severely reduce how
 much rewriting you would have to do as D and dmd change, and the problem would
 become much more tractable.

 - Jonathan M Davis
Sep 28 2011