www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SDC & ddmd

reply dolive <dolive89 sina.com> writes:
Why do need to re-create a new compiler not participate in the maintenance ddmd
?
What better features than ddmd ?
Dec 09 2011
next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
Hi, primary author of SDC here.

Existing compilers (DMD, LDC, GDC, DDMD) all descend directly 
from the DMDFE. The DMDFE is thus the only real source of true 
semantics of the language, except where directly contradicted by 
Walter, Andrei, or TDPL. For the ecosystem to not become inbred, 
a new front-end is needed.

Furthermore, like others, I have become frustrated at the various 
bugs of the frontend. These bugs are passed on to all other 
compilers because of the afore-mentioned ubiquity of the 
front-end.

Lastly, I work on whatever interests me personally, not what 
other people believe to be where my resources would be placed. I 
do not need to defend myself to you.
Dec 09 2011
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Bernard Helyer wrote:
 Hi, primary author of SDC here.

 Existing compilers (DMD, LDC, GDC, DDMD) all descend directly from the
 DMDFE. The DMDFE is thus the only real source of true semantics of the
 language, except where directly contradicted by Walter, Andrei, or TDPL.
 For the ecosystem to not become inbred, a new front-end is needed.

 Furthermore, like others, I have become frustrated at the various bugs
 of the frontend. These bugs are passed on to all other compilers because
 of the afore-mentioned ubiquity of the front-end.

On the other side all bug fixes are also passed on to all compilers. Rewriting entire frontend would certainly introduce another set of bugs.
Dec 09 2011
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Iain Buclaw wrote:
 On 10 December 2011 07:54, Piotr Szturmaj<bncrbme jadamspam.pl>  wrote:
 Bernard Helyer wrote:
 Hi, primary author of SDC here.

 Existing compilers (DMD, LDC, GDC, DDMD) all descend directly from the
 DMDFE. The DMDFE is thus the only real source of true semantics of the
 language, except where directly contradicted by Walter, Andrei, or TDPL.
 For the ecosystem to not become inbred, a new front-end is needed.

 Furthermore, like others, I have become frustrated at the various bugs
 of the frontend. These bugs are passed on to all other compilers because
 of the afore-mentioned ubiquity of the front-end.

On the other side all bug fixes are also passed on to all compilers. Rewriting entire frontend would certainly introduce another set of bugs.

Sure, but that is not an excuse to discourage such development (and we could certainly go turtles all the way down with this argument, as all bugs created are passed on to all compilers too!)

Yes, that was Bernard's argument. :) I'm not against anything and I wish the best for this project. :) However, care must be taken to ensure that compilers are compatible. The number of bugs in DMD bugzilla reminds me how hard it is to implement such compiler.
Dec 10 2011
parent Somedude <lovelydear mailmetrash.com> writes:
Le 10/12/2011 09:52, Piotr Szturmaj a crit :
 Iain Buclaw wrote:
 On 10 December 2011 07:54, Piotr Szturmaj<bncrbme jadamspam.pl>  wrote:
 Bernard Helyer wrote:


 On the other side all bug fixes are also passed on to all compilers.
 Rewriting entire frontend would certainly introduce another set of bugs.

Sure, but that is not an excuse to discourage such development (and we could certainly go turtles all the way down with this argument, as all bugs created are passed on to all compilers too!)

Yes, that was Bernard's argument. :) I'm not against anything and I wish the best for this project. :) However, care must be taken to ensure that compilers are compatible. The number of bugs in DMD bugzilla reminds me how hard it is to implement such compiler.

It also shows that too few people work on the front-end, no matter how good they are (and I believe Walter undoubtly is one of the world's best compiler experts).
Dec 10 2011
prev sibling parent reply Somedude <lovelydear mailmetrash.com> writes:
Le 10/12/2011 08:54, Piotr Szturmaj a écrit :
 Bernard Helyer wrote:
 Hi, primary author of SDC here.

 Existing compilers (DMD, LDC, GDC, DDMD) all descend directly from the
 DMDFE. The DMDFE is thus the only real source of true semantics of the
 language, except where directly contradicted by Walter, Andrei, or TDPL.
 For the ecosystem to not become inbred, a new front-end is needed.

 Furthermore, like others, I have become frustrated at the various bugs
 of the frontend. These bugs are passed on to all other compilers because
 of the afore-mentioned ubiquity of the front-end.

On the other side all bug fixes are also passed on to all compilers. Rewriting entire frontend would certainly introduce another set of bugs.

different behaviors and different bugs on different compilers. Hence that would mean that writing portable code necessits to test it with all compilers.
Dec 10 2011
parent reply Somedude <lovelydear mailmetrash.com> writes:
Le 10/12/2011 10:56, Bernard Helyer a écrit :
 On Saturday, 10 December 2011 at 09:51:08 UTC, Somedude wrote:
 Le 10/12/2011 08:54, Piotr Szturmaj a écrit :
 And it would be *far* more frustrating for the users, who would observe
 different behaviors and different bugs on different compilers. Hence
 that would mean that writing portable code necessits to test it with all
 compilers.

Just like Javascript, HTML, C, C++, Ada, Perl, Fortran, Cobol, and any language in existence that's even remotely widely used?

True, but the difference is, the D community cannot afford to waste its strengths to correct different bugs on several compilers. It is way too small for that.
Dec 10 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/11 3:59 PM, Somedude wrote:
 Le 10/12/2011 10:56, Bernard Helyer a écrit :
 On Saturday, 10 December 2011 at 09:51:08 UTC, Somedude wrote:
 Le 10/12/2011 08:54, Piotr Szturmaj a écrit :
 And it would be *far* more frustrating for the users, who would observe
 different behaviors and different bugs on different compilers. Hence
 that would mean that writing portable code necessits to test it with all
 compilers.

Just like Javascript, HTML, C, C++, Ada, Perl, Fortran, Cobol, and any language in existence that's even remotely widely used?

True, but the difference is, the D community cannot afford to waste its strengths to correct different bugs on several compilers. It is way too small for that.

That's definitely true, but at the same time the notion of "community" is rather amorphous. At the end of the day a community doesn't reason and act like an individual, and no member of the community, however willing, will always act the way that's in the best rational interest of the community. One can't impose people in a community what to work on on their own free time. But things can be improved with good leadership and example. This is something Walter and I want to improve on. Andrei
Dec 10 2011
prev sibling next sibling parent reply dolive <dolive89 sina.com> writes:
Bernard Helyer д:

 Hi, primary author of SDC here.
 
 Existing compilers (DMD, LDC, GDC, DDMD) all descend directly 
 from the DMDFE. The DMDFE is thus the only real source of true 
 semantics of the language, except where directly contradicted by 
 Walter, Andrei, or TDPL. For the ecosystem to not become inbred, 
 a new front-end is needed.
 
 Furthermore, like others, I have become frustrated at the various 
 bugs of the frontend. These bugs are passed on to all other 
 compilers because of the afore-mentioned ubiquity of the 
 front-end.
 
 Lastly, I work on whatever interests me personally, not what 
 other people believe to be where my resources would be placed. I 
 do not need to defend myself to you.

Thank you very much work, one question is: The new front-end can ensure compatibility with dmd , in addition to this would be great . Very much appreciate your work , look forward to an early sdc available. thank's ! dolive
Dec 10 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/10/2011 10:40 AM, Bernard Helyer wrote:
 We intend to be compatible with DMD to a point. Where we are not, will
 be through omission. Off the top of my head:
 [...]
 *D's forward reference and module order bugs will not be supported.

 [snip.]

How is that an 'omission'?
Dec 10 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/10/2011 10:54 AM, Bernard Helyer wrote:
 On Saturday, 10 December 2011 at 09:47:14 UTC, Timon Gehr wrote:
 On 12/10/2011 10:40 AM, Bernard Helyer wrote:
 We intend to be compatible with DMD to a point. Where we are not, will
 be through omission. Off the top of my head:
 [...]
 *D's forward reference and module order bugs will not be supported.

 [snip.]

How is that an 'omission'?

Just my lame attempt at humour. :P

Should have thought of that. =) Do you already have a working design? I think what Don suggested (process static if and mixins in sequence, everything else on by need basis) does not work in the general case because you can have static if and mixin declaration dependencies across module import cycles. I think the way it should work would be similar to this sketch: Evaluate all static if's and mixin declarations until a symbol not defined in the current scope is hit. Repeat. As soon as all remaining mixins and static ifs have been blocked like that, consider the enclosing scope and decide that the symbol does not exist in the current scope. Repeat the whole process until a fixed point is reached. At that point decide that all remaining unresolved symbols do not exist. Repeat until everything is evaluated. If at any point a symbol is defined that has been decided not to exist in another mixin or static if declaration, emit an 'illegally dependent on static evaluation order' error. It is not exactly trivial to get right, but if I am not mistaken, the result should be powerful, intuitive and evaluation order independent. It even allows patterns like static if(!is(typeof(foo)) enum foo = bar();, while banning static if(!is(typeof(bar)) enum foo = 1; static if(!is(typeof(foo)) enum bar = 1;
Dec 10 2011
parent reply Don <nospam nospam.com> writes:
On 10.12.2011 12:17, Timon Gehr wrote:
 On 12/10/2011 10:54 AM, Bernard Helyer wrote:
 On Saturday, 10 December 2011 at 09:47:14 UTC, Timon Gehr wrote:
 On 12/10/2011 10:40 AM, Bernard Helyer wrote:
 We intend to be compatible with DMD to a point. Where we are not, will
 be through omission. Off the top of my head:
 [...]
 *D's forward reference and module order bugs will not be supported.

 [snip.]

How is that an 'omission'?

Just my lame attempt at humour. :P

Should have thought of that. =) Do you already have a working design? I think what Don suggested (process static if and mixins in sequence, everything else on by need basis) does not work in the general case because you can have static if and mixin declaration dependencies across module import cycles.

Do you have an example? Would be good to discuss.
Dec 15 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/15/2011 05:47 PM, Don wrote:
 On 10.12.2011 12:17, Timon Gehr wrote:
 On 12/10/2011 10:54 AM, Bernard Helyer wrote:
 On Saturday, 10 December 2011 at 09:47:14 UTC, Timon Gehr wrote:
 On 12/10/2011 10:40 AM, Bernard Helyer wrote:
 We intend to be compatible with DMD to a point. Where we are not, will
 be through omission. Off the top of my head:
 [...]
 *D's forward reference and module order bugs will not be supported.

 [snip.]

How is that an 'omission'?

Just my lame attempt at humour. :P

Should have thought of that. =) Do you already have a working design? I think what Don suggested (process static if and mixins in sequence, everything else on by need basis) does not work in the general case because you can have static if and mixin declaration dependencies across module import cycles.

Do you have an example? Would be good to discuss.

OK: --- module a; import b; static if(!is(typeof(be))){ enum not_be=1; pragma(msg,"not to be!"); } --- --- module b; import a; static if(!is(typeof(not_be))){ enum be=1; pragma(msg,"to be!"); } --- --- $ dmd a b -o- to be! $ dmd b a -o- not to be! --- The compiler should reject it. There is no correct way to compile it.
Dec 15 2011
prev sibling parent dolive <dolive89 sina.com> writes:
Bernard Helyer д:

 Hi, primary author of SDC here.
 
 Existing compilers (DMD, LDC, GDC, DDMD) all descend directly 
 from the DMDFE. The DMDFE is thus the only real source of true 
 semantics of the language, except where directly contradicted by 
 Walter, Andrei, or TDPL. For the ecosystem to not become inbred, 
 a new front-end is needed.
 
 Furthermore, like others, I have become frustrated at the various 
 bugs of the frontend. These bugs are passed on to all other 
 compilers because of the afore-mentioned ubiquity of the 
 front-end.
 
 Lastly, I work on whatever interests me personally, not what 
 other people believe to be where my resources would be placed. I 
 do not need to defend myself to you.

Roadmap whether the marked date ? thank's ! dolive
Dec 10 2011
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, �� December 2011 at 05:48:18 UTC, dolive wrote:
 Why do need to re-create a new compiler not participate in the 
 maintenance ddmd ?
 What better features than ddmd ?

I assume you are comparing SDC and DDMD on the basis that they're both written in D. While being written in D is a main point for SDC, it's not the only one. SDC is written from scratch with no other dependency than LLVM. Like LDC, it uses LLVM for the back-end, but unlike LDC, it doesn't use the DMD front-end. GDC and LDC inherit all the advantages and disadvantages of the DMD front-end. They get the whole language, or at least as far as the reference compiler implements it, up front. But they also get all the baggage of DMD: bugs, legacy code, etc. The SDC front-end is written with only D2 in mind and inherits no code from any C++ or D1 compiler, while DMD was built incrementally while D was a moving target. Due to all of this, the design of the codebase is fundamentally different from DMD. On the other hand, DDMD is a massive project in its own right. First you have to convert all of DMD's sources to D, then you can get onto the real task: turning the new code into idiomatic D instead of "C++ with a D compiler". And you have to keep it up to date with DMD development until DDMD is ready to take over. It's not yet clear which approach is "better", only time will tell. But the SDC project has already reaped benefits from its approach, and the design allows for many improvements as the project moves forward. Do note that as an SDC dev, I do have a bias in this comparison, but feel free to come up with some actual arguments for DDMD :)
Dec 09 2011
next sibling parent dolive <dolive89 sina.com> writes:
Jakob Ovrum д:

 On Saturday, �� December 2011 at 05:48:18 UTC, dolive wrote:
 Why do need to re-create a new compiler not participate in the 
 maintenance ddmd ?
 What better features than ddmd ?

I assume you are comparing SDC and DDMD on the basis that they're both written in D. While being written in D is a main point for SDC, it's not the only one. SDC is written from scratch with no other dependency than LLVM. Like LDC, it uses LLVM for the back-end, but unlike LDC, it doesn't use the DMD front-end. GDC and LDC inherit all the advantages and disadvantages of the DMD front-end. They get the whole language, or at least as far as the reference compiler implements it, up front. But they also get all the baggage of DMD: bugs, legacy code, etc. The SDC front-end is written with only D2 in mind and inherits no code from any C++ or D1 compiler, while DMD was built incrementally while D was a moving target. Due to all of this, the design of the codebase is fundamentally different from DMD. On the other hand, DDMD is a massive project in its own right. First you have to convert all of DMD's sources to D, then you can get onto the real task: turning the new code into idiomatic D instead of "C++ with a D compiler". And you have to keep it up to date with DMD development until DDMD is ready to take over. It's not yet clear which approach is "better", only time will tell. But the SDC project has already reaped benefits from its approach, and the design allows for many improvements as the project moves forward. Do note that as an SDC dev, I do have a bias in this comparison, but feel free to come up with some actual arguments for DDMD :)

Thank you for detailed explanation, Whether the design can refer to dil international support ideas(I have the impression). Language packs can be provided by a third party. thank's ! dolive
Dec 10 2011
prev sibling parent Hans Uhlig <hans.uhlig teamaol.com> writes:
Are you building SDC in the same fashion as clang by chance where the 
pieces are modular and usable else ware? (such as the parser being able 
to be used in an ide?)

On 12/9/2011 10:25 PM, Jakob Ovrum wrote:
 On Saturday, �� December 2011 at 05:48:18 UTC, dolive wrote:
 Why do need to re-create a new compiler not participate in the
 maintenance ddmd ?
 What better features than ddmd ?

I assume you are comparing SDC and DDMD on the basis that they're both written in D. While being written in D is a main point for SDC, it's not the only one. SDC is written from scratch with no other dependency than LLVM. Like LDC, it uses LLVM for the back-end, but unlike LDC, it doesn't use the DMD front-end. GDC and LDC inherit all the advantages and disadvantages of the DMD front-end. They get the whole language, or at least as far as the reference compiler implements it, up front. But they also get all the baggage of DMD: bugs, legacy code, etc. The SDC front-end is written with only D2 in mind and inherits no code from any C++ or D1 compiler, while DMD was built incrementally while D was a moving target. Due to all of this, the design of the codebase is fundamentally different from DMD. On the other hand, DDMD is a massive project in its own right. First you have to convert all of DMD's sources to D, then you can get onto the real task: turning the new code into idiomatic D instead of "C++ with a D compiler". And you have to keep it up to date with DMD development until DDMD is ready to take over. It's not yet clear which approach is "better", only time will tell. But the SDC project has already reaped benefits from its approach, and the design allows for many improvements as the project moves forward. Do note that as an SDC dev, I do have a bias in this comparison, but feel free to come up with some actual arguments for DDMD :)

Dec 19 2011
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 December 2011 07:54, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:
 Bernard Helyer wrote:
 Hi, primary author of SDC here.

 Existing compilers (DMD, LDC, GDC, DDMD) all descend directly from the
 DMDFE. The DMDFE is thus the only real source of true semantics of the
 language, except where directly contradicted by Walter, Andrei, or TDPL.
 For the ecosystem to not become inbred, a new front-end is needed.

 Furthermore, like others, I have become frustrated at the various bugs
 of the frontend. These bugs are passed on to all other compilers because
 of the afore-mentioned ubiquity of the front-end.

On the other side all bug fixes are also passed on to all compilers. Rewriting entire frontend would certainly introduce another set of bugs.

Sure, but that is not an excuse to discourage such development (and we could certainly go turtles all the way down with this argument, as all bugs created are passed on to all compilers too!) Things that rock about SDC from my short observation of seeing it develop. It's a compiler written in D2 for D2, and aims to be self-hosting. (At least I hope that is still the goal. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 10 2011
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 10 Dec 2011 07:23:00 +0100
"Bernard Helyer" <b.helyer gmail.com> wrote:

Hello Bernard,

 Lastly, I work on whatever interests me personally, not what=20
 other people believe to be where my resources would be placed. I=20
 do not need to defend myself to you.

+1 Prospect of having self-hosting D2 compiler is great in itself - no need to defend it at all. Keep up the good work and let's hope we'll one day get a new & robust D compiler!! Sincerely, Gour --=20 One who is not connected with the Supreme can have neither=20 transcendental intelligence nor a steady mind, without which=20 there is no possibility of peace. And how can there be any=20 happiness without peace? http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 10 2011
prev sibling next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
We intend to be compatible with DMD to a point. Where we are not, 
will be through omission. Off the top of my head:

*delete will not be implemented.
*scope classes will not be implemented.
*complex numbers will not be implemented.
*version/debug levels will not be implemented, as their semantics 
are poorly documented, and I've never seen them used in any code 
anywhere.
*C style function pointers will not be supported.
*The D calling convention will not be matched, at least not in 1.0
(extern (D) is currently fastcall)
*D's forward reference and module order bugs will not be 
supported.

And others I've probably forgotten. In terms of release date, I 
can't really say, sorry. Currently working on the D interpreter 
for CTFE and constant expressions, if you're interested. :D


-Bernard.
Dec 10 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bernard Helyer:

 *version/debug levels will not be implemented, as their semantics 
 are poorly documented,

Then I suggest to file a documentation bug in Bugzilla that lists where the D docs are not clear enough about version/debug levels semantics. Bye, bearophile
Dec 10 2011
prev sibling parent dolive <dolive89 sina.com> writes:
Bernard Helyer Wrote:

 We intend to be compatible with DMD to a point. Where we are not, 
 will be through omission. Off the top of my head:
 
 *delete will not be implemented.
 *scope classes will not be implemented.
 *complex numbers will not be implemented.
 *version/debug levels will not be implemented, as their semantics 
 are poorly documented, and I've never seen them used in any code 
 anywhere.
 *C style function pointers will not be supported.
 *The D calling convention will not be matched, at least not in 1.0
 (extern (D) is currently fastcall)
 *D's forward reference and module order bugs will not be 
 supported.
 
 And others I've probably forgotten. In terms of release date, I 
 can't really say, sorry. Currently working on the D interpreter 
 for CTFE and constant expressions, if you're interested. :D
 
 
 -Bernard.
 

So many features are not implemented can be compatible with dmd2 ? In addition , the current sdc in what state? Feature list is up to date? what time is expected time to be completed for 0.1? Good luck! dolive
Dec 17 2011
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 10 December 2011 at 09:47:14 UTC, Timon Gehr wrote:
 On 12/10/2011 10:40 AM, Bernard Helyer wrote:
 We intend to be compatible with DMD to a point. Where we are 
 not, will
 be through omission. Off the top of my head:
 [...]
 *D's forward reference and module order bugs will not be 
 supported.

 [snip.]

How is that an 'omission'?

Just my lame attempt at humour. :P
Dec 10 2011
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 10 December 2011 at 09:51:08 UTC, Somedude wrote:
 Le 10/12/2011 08:54, Piotr Szturmaj a écrit :
 And it would be *far* more frustrating for the users, who would 
 observe
 different behaviors and different bugs on different compilers. 
 Hence
 that would mean that writing portable code necessits to test it 
 with all
 compilers.

Just like Javascript, HTML, C, C++, Ada, Perl, Fortran, Cobol, and any language in existence that's even remotely widely used?
Dec 10 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, December 10, 2011 22:59:48 Somedude wrote:
 Le 10/12/2011 10:56, Bernard Helyer a =C3=A9crit :
 On Saturday, 10 December 2011 at 09:51:08 UTC, Somedude wrote:
 Le 10/12/2011 08:54, Piotr Szturmaj a =C3=A9crit :
 And it would be *far* more frustrating for the users, who would
 observe
 different behaviors and different bugs on different compilers. Hen=



 that would mean that writing portable code necessits to test it wi=



 all
 compilers.

Just like Javascript, HTML, C, C++, Ada, Perl, Fortran, Cobol, and =


 language in existence that's even remotely widely used?

True, but the difference is, the D community cannot afford to waste i=

 strengths to correct different bugs on several compilers. It is way t=

 small for that.

In the short term, I think that we'd be better off having people who wa= nt to=20 work on D focusing on the improving existing compilers and the standard= =20 libraries. However, in the long term, we would definitely be benefited = by having=20 more compilers. And just because someone is willing to work on a new co= mpiler=20 doesn't mean that they'd be willing to work on an existing one or on th= e=20 standard libraries. So, it's not necessarily the case that we're gettin= g any=20 less work done on dmd or Phobos because people are working on SDC. Also= , it's=20 quite possible that those working on SDC will find issues with the D sp= ec and=20 with dmd which might not be found otherwise, and the spec and dmd can b= enefit=20 from that. So, while I'm skeptical that creating a new compiler is really the best= use of=20 manpower for D at this point, I see no problem with the SDC devs workin= g on=20 that if that's what they want to do. And even those who have no interes= t in=20 SDC can still benefit from their efforts. By the way. I didn't even know that SDC existed before this. It's inter= esting=20 to see that another D compiler is in the works - especially since it's = being=20 written in D. Having lower-level, performance-critical work like that b= eing=20 done in D will definitely be of benefit in finding issues in the langua= ge and=20 existing compiler implementations, regardless of where the SDC project=20= ultimately goes. - Jonathan M Davis
Dec 10 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/10/11, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 and no member of the community, however
 willing, will always act the way that's in the best rational interest of
 the community.

I think writing a D compiler from scratch in a "D-tonic" way is in the best interest of the community, much more so than hacking on a C++(!) compiler or a 1to1 translation of it (DDMD). As D gets more popular we'll hopefully shrink the dependency on existing C++ codebases (where practicle).
Dec 10 2011
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 10 December 2011 at 11:17:19 UTC, Timon Gehr wrote:
 On 12/10/2011 10:54 AM, Bernard Helyer wrote:
 On Saturday, 10 December 2011 at 09:47:14 UTC, Timon Gehr 
 wrote:
 How is that an 'omission'?

Just my lame attempt at humour. :P

Should have thought of that. =) Do you already have a working design? I think what Don suggested (process static if and mixins in sequence...<snip>

Nothing so elegant, I'm afraid. Each module has all top level declarations added to a list, SDC then iterates over the list trying to resolve them appropriately. If it can, it marks it as done and moves to the next. If it can't it increments the "can't resolve" counter and keeps going. If on a given loop the can't resolve counter is zero, then a source of top level declarations (static if, import statements, version blocks, etc) is added to the list. This keeps going until the entire list is handled, or we've hit an impossible situation. Rather simplistic, but we haven't had any trouble with it yet.
Dec 11 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 Are you building SDC in the same fashion as clang by chance where the  
 pieces are modular and usable else ware? (such as the parser being able  
 to be used in an ide?)

It isn't as well-conceived. Hence the name, it started out as a toy project and didn't have Clang-like goals in mind. For example last time I looked there was no proper interface between the parser and "consumers". Instead an AST is always built. Errors were processed by simply throwing exceptions etc. and the code was sparsely documented.
Dec 19 2011
prev sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Monday, 19 December 2011 at 22:59:37 UTC, Trass3r wrote:
 Are you building SDC in the same fashion as clang by chance 
 where the pieces are modular and usable else ware? (such as 
 the parser being able to be used in an ide?)

It isn't as well-conceived. Hence the name, it started out as a toy project and didn't have Clang-like goals in mind. For example last time I looked there was no proper interface between the parser and "consumers". Instead an AST is always built. Errors were processed by simply throwing exceptions etc. and the code was sparsely documented.

You'd think making the first letter stand for 'stupid' would tip people off. :P
Dec 19 2011