On 12/4/2013 4:16 AM, Shammah Chancellor wrote:
> With the version, is there any chance of LLVM being the default backend -- or is
> Walter opposed to that?

I'm opposed to it.

For one example, a year ago I had to make dmd work on Win64. LLVM didn't support Win64. I would have been stymied.

It is very good for D to have 3 equivalent implementations - dmd, gdc, and ldc. Each has its strengths and weaknesses. It makes for a very strong ecosystem.

On Wednesday, 4 December 2013 at 22:11:46 UTC, Walter Bright wrote:
> On 12/4/2013 2:33 AM, eles wrote:
>> On Sunday, 1 December 2013 at 06:43:13 UTC, Walter Bright wrote:
>>> On 11/30/2013 1:19 PM, Chris Cain wrote:

>> but they give a nice convoluted counter-example; read this:
>>
>> int (*(*fp)(int (*)(int, int), int))(int, int)
>
> It's not a counterexample. It's still the same as how you'd use it in an expression.

yes, it is not a counter-example to the C's choice, only to the human capacity to read declarations.

"Shammah Chancellor" <anonymous@coward.com> wrote in message news:l7n6fh$16s0$1@digitalmars.com...
>>
>> Yeah.  See: http://forum.dlang.org/post/khkst4$13ad$1@digitalmars.com http://forum.dlang.org/post/jqvduhyvfufpzovpyqbj@forum.dlang.org
>>
>> Patches against dmd:
>> https://github.com/D-Programming-Language/dmd/pull/1980
>> Converter tool: https://github.com/yebblies/magicport2
>> Pull requests marked DDMD:
>> https://github.com/D-Programming-Language/dmd/pulls/yebblies
>
>
> This is AWESOME!!!!   Keep up the good work.  Can't wait to see how the DMD frontend performs in D.
>

From a quick test, compiling ddmd with ddmd takes about 80% longer than compiling ddmd with c++dmd.  I suspect a lot of this is from not using the tuned allocator from the C++ version.

> With the version, is there any chance of LLVM being the default backend -- or is Walter opposed to that?
>

As Walter said, there is no chance of that happening.  However, we are slowly working to integrate or refactor away all gdc/ldc patches against the frontend.  This should greatly reduce the effort to merge patches, hopefully resulting in all three compilers permanently being in sync.

On Thu, Dec 05, 2013 at 02:08:34PM +1100, Daniel Murphy wrote:
> "Shammah Chancellor" <anonymous@coward.com> wrote in message news:l7n6fh$16s0$1@digitalmars.com...
[...]
> > With the version, is there any chance of LLVM being the default backend --  or is Walter opposed to that?
> >
> 
> As Walter said, there is no chance of that happening.  However, we are slowly working to integrate or refactor away all gdc/ldc patches against the frontend.  This should greatly reduce the effort to merge patches, hopefully resulting in all three compilers permanently being in sync.

I'm looking forward to that. Recently I've been working on a compute-intensive program, and I've been hoping to test it with gdc to get maximal performance, but since I developed the code mainly with dmd git HEAD, it doesn't compile with gdc, which is rather frustrating. It would be great if the three compilers are always in sync -- if gdc could, for example, just pull straight from DFE git HEAD and Just Work(tm).


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."

On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
> Also does everybody like the graphics at the top of http://dconf.org/2014/index.html?
>
Frankly, it's awful.

On 2013-12-04 23:14, Walter Bright wrote:

> For one example, a year ago I had to make dmd work on Win64. LLVM didn't
> support Win64. I would have been stymied.

The answer to that would be: contribute that implementation to LLVM. But I know you're opposed to that as well.

If they don't accept the contributions, use a fork.

-- 
/Jacob Carlborg

On 12/4/13 10:57 PM, Martin Nowak wrote:
> On Tuesday, 3 December 2013 at 20:53:28 UTC, Andrei Alexandrescu wrote:
>> Also does everybody like the graphics at the top of
>> http://dconf.org/2014/index.html?
>>
> Frankly, it's awful.

I agree!!

Andrei

On 12/5/2013 12:11 AM, Jacob Carlborg wrote:
> On 2013-12-04 23:14, Walter Bright wrote:
>
>> For one example, a year ago I had to make dmd work on Win64. LLVM didn't
>> support Win64. I would have been stymied.
>
> The answer to that would be: contribute that implementation to LLVM. But I know
> you're opposed to that as well.
>
> If they don't accept the contributions, use a fork.


Easy to say, but doing Win64 was a major effort:

1. bizarre function calling conventions

2. undocumented symbolic debug info format

3. new object file format

Making such changes on a backend without thoroughly understanding how the backend works would be quite a challenge. I seriously doubt anyone could have done that on the tight schedule I was under.

Besides, forking LLVM subverts most of the advantages of using it.

On Saturday, 30 November 2013 at 18:16:23 UTC, Walter Bright wrote:
> It's easier than that:
>
> struct Rectangular {
>     Point x,y;
> }
>
> struct Rectangular {
>     Rectangle rectangle;
>     alias this rectangle;
> }

The other day in IRC I asked about the transition to the newer alias X = Type syntax (I would love to see it everywhere!), and someone was saying that the "alias this" syntax always tripped him, because the name misleadingly suggests that the 'this' comes after the 'alias'. I guess it trips everybody :-)

On 2013-12-06 03:02, Walter Bright wrote:

> Easy to say, but doing Win64 was a major effort:
>
> 1. bizarre function calling conventions
>
> 2. undocumented symbolic debug info format
>
> 3. new object file format
>
> Making such changes on a backend without thoroughly understanding how
> the backend works would be quite a challenge. I seriously doubt anyone
> could have done that on the tight schedule I was under.

Yes, I understand that. Hopefully you wouldn't have moved to LLVM and at the same time implement Win64. Meaning that hopefully you would have had better knowledge about the LLVM source code when starting with Win64.

> Besides, forking LLVM subverts most of the advantages of using it.

Just fold in the changes from upstream. Yes, I know that won't be as easy as having the code merged with upstream.

-- 
/Jacob Carlborg