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 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
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.


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.
Dec 10 2011
parent reply "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
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
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=






ce

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






th

 all
 compilers.


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




any

 language in existence that's even remotely widely used?


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


ts

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


oo

 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 parent reply 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
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 Gour <gour atmarama.net> writes:
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 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 "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 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 "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
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
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 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 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 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 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 reply 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
parent reply 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
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