On 1 March 2013 10:43, Jacob Carlborg <doob@me.com> wrote:

> On 2013-03-01 11:29, Iain Buclaw wrote:
>
>  The code that interfaces with gcc needs to be in either C or C++.  There
>> are C++ structs/classes defined in the D frontend that while they include all methods required for parsing/semantic analysis of D code. They also include methods that are used to generate the codegen for the backend (toElem, toIR, toSymbol, etc).  In gdc, these are gcc interfacing methods that can't be converted to D.
>>
>
> Can you use the current toElem, toIR and toSymbol written in C++. Then port in changes from the version written in D as needed?
>
> --
> /Jacob Carlborg
>


Also, what changes dmd makes to it's back-end facing functions do not necessarily affect gdc.  So there has never really been a direct conversion from one to the other, however as they (should) do effectively the same code generation, one can draw comparisons between them.

Regards,
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 03/01/2013 11:08 AM, dennis luehring wrote:
> Am 01.03.2013 10:54, schrieb Vincent:
> ...
>  >Anyway, I offer to keep away from C++ code - it's written with
>  >"C++ in mind", while D offers brand new world. So I support
>  >rewritting D on D from scratch.
>
> that will just not work for an project of that size - or better - there
> are several tries of from-scratch without success out there
> ...

As well as some that will likely become successful.
Anyway, imo both should be attempted.

On Thursday, 28 February 2013 at 00:37:50 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> Walter and I have had a long conversation about the next radical thing to do to improve D's standing. Like others in this community, we believe it's a good time to consider bootstrapping the compiler. Having the D compiler written in D has quite a few advantages, among which taking advantages of D's features and having a large codebase that would be its own test harness.
>
> By this we'd like to initiate a dialog about how this large project can be initiated and driven through completion. Our initial basic ideas are:
>
> 1. Implement the dtoh standalone program that takes a D module and generates its corresponding C++ header.
>
> 2. Use dtoh to initiate and conduct an incremental port of the compiler. At given points throughout the code D code will coexist and link with C++ code.
>
> 3. At a point in the future the last C++ module will be replaced with a D module. Going forward there will be no more need for a C++ compiler to build the compiler (except as a bootstrapping test).
>
> It is essential that we get support from the larger community for this. This is a large project that should enjoy strong leadership apart from Walter himself (as he is busy with dynamic library support which is strategic) and robust participation from many of us.
>
> Please chime in with ideas on how to make this happen.

This would be a huge step forward, I'm sure all of us who have made significant contributions to the compiler are frustrated by the many things that are difficult in C++ but would be easy in D.

But in my view, before step 2 can happen, we need to clean up the glue layer.
Once we have an isolated, clearly defined front-end that is shared between dmd, gdc and ldc, we can start converting it.

On 01.03.2013 07:10, Russel Winder wrote:
> Walter,
>
> On Thu, 2013-02-28 at 14:46 -0800, Walter Bright wrote:
> […]
>> I know I probably come off as a ninny about this, but professional users will
>> run screaming from any open source code unless it contains:
>>
>> 1. a copyright notice
>> 2. a license
>> 3. who owns the above
>
> Not ninni-ish at all, very sensible. Of course it is not the
> professional users that worry about these things, it is their lawyers.
> Worse there is a whole collection of misunderstanding and
> misapprehensions, not to mention FUD, about the various well known
> licences.
>

I lost count the amount of times I had to fulfill Excel sheets with information for Lawyers before we could use open source software.

Some of those sheets are pretty exhaustive. :\

- License
- Owner
- Web site
- Code repository location for the given release number
- In which product it is going to be used
- Why we are using open source in first place
- Examples of known software that also make use of the related software
- ...

This for each single version being used. A new version requires going again through the process.

--
Paulo

On Fri, Mar 01, 2013 at 04:28:50PM +0100, Paulo Pinto wrote:
> On 01.03.2013 07:10, Russel Winder wrote:
> >Walter,
> >
> >On Thu, 2013-02-28 at 14:46 -0800, Walter Bright wrote: […]
> >>I know I probably come off as a ninny about this, but professional users will run screaming from any open source code unless it contains:
> >>
> >>1. a copyright notice
> >>2. a license
> >>3. who owns the above
> >
> >Not ninni-ish at all, very sensible. Of course it is not the professional users that worry about these things, it is their lawyers.  Worse there is a whole collection of misunderstanding and misapprehensions, not to mention FUD, about the various well known licences.
> >
> 
> I lost count the amount of times I had to fulfill Excel sheets with information for Lawyers before we could use open source software.
> 
> Some of those sheets are pretty exhaustive. :\
> 
> - License
> - Owner
> - Web site
> - Code repository location for the given release number
> - In which product it is going to be used
> - Why we are using open source in first place
> - Examples of known software that also make use of the related software
> - ...
> 
> This for each single version being used. A new version requires going again through the process.
[...]

Wow. You make me feel really lucky that at my day job, I once made a request to use a particular piece of open source software, and the legal department actually replied with "the license is MIT, it should be OK, approved."

OTOH, though, anything to do with the GPL or its ilk will probably require truckloads of red tape to approve.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

On Friday, 1 March 2013 at 10:36:04 UTC, Jonathan M Davis wrote:
> On Friday, March 01, 2013 09:50:13 Thomas Koch wrote:
>> > Walter and I have had a long conversation about the next radical thing
>> > to do to improve D's standing. Like others in this community, we believe
>> > it's a good time to consider bootstrapping the compiler. Having the D
>> > compiler written in D has quite a few advantages, among which taking
>> > advantages of D's features and having a large codebase that would be its
>> > own test harness.
>> 
>> Two points from the viewpoint of the Debian distribution:
>> 
>> Debian is ported to many different platforms and in average one new platform
>> port started every year. A huge pain point for porters are circular (or
>> self) dependencies. A lot of effort goes into breaking such circles.
>> 
>> So in the moment the D language is great in that it does not introduce a new
>> circular dependency. It would be a pity to lose this.
>> 
>> The second important thing for Debian (and Fedora and others) is licensing.
>> It's a pity that DMD isn't free software and I believe DMD not being in
>> distros is one reason for the low popularity of D. It's hard to learn D with
>> gdc while all tutorials are based on DMD.
>> 
>> So instead of a rewrite of D, it would rather be important (from my humble
>> point of view) to replace non-free parts of DMD.
>
> I don't really care about the license, but I can definitely say that part of me
> finds the idea of having a compiler compiling itself to be a bad idea, much is
> compiler folks love to do that. Recently, I had some older haskell code that I
> needed to compile, but it followed the previous haskell standard, and I
> couldn't get the current compiler to compile it even in compatability mode.
> So, I tried to compile an older version of the compiler from before the new
> standard, and it had exactly the same problems that my code did, because it
> was written in haskell using the older standard. So, I had to give up on being
> able to compile my code, because I couldn't get my hands on an old enough
> version of the compiler. If they'd just written it in C/C++, then I wouldn't
> have had that problem.
>
> I know that it's generally touted as a great idea for a language to compile
> itself, and I'm sure that it would be great to be able to use D's features in
> the compiler, but the circular dependency that that causes is a definite
> negative IMHO.
>
> - Jonathan M Davis

There is no problem with circular dependencies as long as the language spec has a fixed subset that the compiler is written in. The reason is that any future version then can compile the compiler source because the future versions all support the subset.

This is why it is so important to get the fixed language subset down because it will the core language features and can't be changed without causing regressive dependencies.

Any evolution of the D compiler will compile it's own compiler source as long as it properly implements the D language subset. This subset also has to be a subset of the current dmd language implementation to bootstrap from.

On Fri, Mar 01, 2013 at 05:44:52PM +0100, js.mdnq wrote:
> On Friday, 1 March 2013 at 10:36:04 UTC, Jonathan M Davis wrote:
[...]
> >I don't really care about the license, but I can definitely say that part of me finds the idea of having a compiler compiling itself to be a bad idea, much is compiler folks love to do that. Recently, I had some older haskell code that I needed to compile, but it followed the previous haskell standard, and I couldn't get the current compiler to compile it even in compatability mode.  So, I tried to compile an older version of the compiler from before the new standard, and it had exactly the same problems that my code did, because it was written in haskell using the older standard. So, I had to give up on being able to compile my code, because I couldn't get my hands on an old enough version of the compiler. If they'd just written it in C/C++, then I wouldn't have had that problem.
> >
> >I know that it's generally touted as a great idea for a language to compile itself, and I'm sure that it would be great to be able to use D's features in the compiler, but the circular dependency that that causes is a definite negative IMHO.
> >
> >- Jonathan M Davis
> 
> There is no problem with circular dependencies as long as the language spec has a fixed subset that the compiler is written in. The reason is that any future version then can compile the compiler source because the future versions all support the subset.
> 
> This is why it is so important to get the fixed language subset down because it will the core language features and can't be changed without causing regressive dependencies.
> 
> Any evolution of the D compiler will compile it's own compiler source as long as it properly implements the D language subset. This subset also has to be a subset of the current dmd language implementation to bootstrap from.

+1.

Another reason I keep saying that we need to write the D compiler in a fixed subset of D. There are many advantages to this. For one, it will solve the GDC situation -- we can just ship the last C++ version of DMD with GDC (outdated but it will correctly compile the newest D compiler), then it can be used to compile the D version of the compiler.

Then there's the above point, that if the last C++ version of DMD is capable of compiling the latest D version of DMD, then we won't run into the situation where you can't compile anything unless you checkout successive versions of DMD just to be able to compile the next one.

Restricting DMD to a fixed subset of D also means that it will not be vulnerable to subtle bugs caused by later breaking changes to the language. Let's just face it, the current version of D is far from breaking changes, even if we're trying our best to stabilize it. Using a fixed subset of D to write the compiler ensures that all versions of the compiler are compilable by all other versions of it, which comes in very useful when you end up in Jonathan's situation above.


T

-- 
One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion

On Thursday, 28 February 2013 at 00:37:50 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> Walter and I have had a long conversation about the next radical thing to do to improve D's standing. Like others in this community, we believe it's a good time to consider bootstrapping the compiler. Having the D compiler written in D has quite a few advantages, among which taking advantages of D's features and having a large codebase that would be its own test harness.
..

Strategically it is great idea, but tactically there are probably more
attractive (for new users also) areas to improve toolchain:

- GC. Current solution is just like java's from 90th. Hit all OS and mostly everybody. Makes so hard to develop solutions with soft-RT requirements, like
games and multimedia processing.
- Linker for Windows. optlink is far away from current industry requirements/standarts. Using coff for Win64 is good but we have now dependency on external toolchain. Unfortunatelly C++/CLI was excluded from SDK'12, it probably shows new trend. How long SDK'10 will be available for download and compatible with next Windows? Big risk.

Good article on what can replace C from Damien, including D -
http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html

> - GC. Current solution is just like java's from 90th. Hit all OS and mostly everybody. Makes so hard to develop solutions with soft-RT requirements, like
> games and multimedia processing.

For those use cases, it may be more productive to make avoiding the GC easier than to try to improve GC's performance (not that making the GC faster is a bad thing).

On Friday, 1 March 2013 at 08:55:22 UTC, Timon Gehr wrote:
> On 03/01/2013 07:48 AM, Marco Leise wrote:
>> Am Thu, 28 Feb 2013 18:44:31 +0100
>> schrieb Timon Gehr <timon.gehr@gmx.ch>:
>>
>>> * wc -l reveals that the DMD front end source code is roughly 30 to 40
>>> times larger than it should be for what it does in my opinion.
>>
>> That can only mean that you don't really know what it does in
>> my opinion.
>
> I guess it (almost) implements the language. :)
>
>> Sure such a large code base accumulates duplicates
>> since not everybody knows about all helper functions or copy
>> and paste was the least intrusive bug fix somewhere, but you
>> don't really believe that 94% of the front end are
>> unnecessary, do you?
>>
>
> I believe it is bloated. Maybe it's partly because it is written in C++.
>
>> ...

I have to go with Marco. What is the usual bloat factor between C++ and D ? 2x at most ? Unless you found some super efficient way of writing a complex grammar, I don't see a reason there could be such a large difference.
In fact, for this kind of program, I am not even sure the D code will be much smaller than the C++ one overall.