On 7/31/18 2:24 PM, Walter Bright wrote:
> On 7/27/2018 4:03 AM, Seb wrote:
>> This a thread to explore whether it would be feasible to do so.
> 
> Since DMD and Druntime require each other, it is the right thing to do.

I think this is an incorrect relationship.

DMD does NOT require Druntime, *testing* DMD requires Druntime.

In fact, I thought the whole point of the -betterC feature was to eliminate any dependency on druntime.

As we move to more and more library-provided hooks and away from "compiler magic", this coupling will become less and less prevalent.

In fact, most of the changes that require both projects to be simultaneously to be updated are these magic-removing ones.

If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler.

-Steve

On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote:
> On 7/31/18 2:24 PM, Walter Bright wrote:
>> Since DMD and Druntime require each other, it is the right thing to do.
>
> I think this is an incorrect relationship.
>
> DMD does NOT require Druntime, *testing* DMD requires Druntime.

Well DMD ships just happens to ship with Druntime ;-)

> In fact, I thought the whole point of the -betterC feature was to eliminate any dependency on druntime.

That's only partially true. Even with -betterC, `object.d` will still be imported by default and actually many language features that work in -betterC will be lowered to druntime (even in betterC):

One simple example: https://run.dlang.io/is/41vvoO

> As we move to more and more library-provided hooks and away from "compiler magic", this coupling will become less and less prevalent.

On the contrary, DMD will depend more and more on druntime as the magic is now in druntime and not in the dmd source code.

> In fact, most of the changes that require both projects to be simultaneously to be updated are these magic-removing ones.

Yes and no. Whenever you want to update a library hooks (which are implementation-defined and not part of the specification), it's rather complicated to do with keeping all CIs happy.

> If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler.

Good idea!

On 7/31/18 4:48 PM, Seb wrote:
> On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote:
>> On 7/31/18 2:24 PM, Walter Bright wrote:
>>> Since DMD and Druntime require each other, it is the right thing to do.
>>
>> I think this is an incorrect relationship.
>>
>> DMD does NOT require Druntime, *testing* DMD requires Druntime.
> 
> Well DMD ships just happens to ship with Druntime ;-)

What I mean is that one can build and use DMD without druntime (see Mike Franklin's project from 2013). The test suite requires it because we are testing the interactions between the DMD binary and the runtime that it uses. This whole thread is really about testing.

>> In fact, I thought the whole point of the -betterC feature was to eliminate any dependency on druntime.
> 
> That's only partially true. Even with -betterC, `object.d` will still be imported by default and actually many language features that work in -betterC will be lowered to druntime (even in betterC):
> 
> One simple example: https://run.dlang.io/is/41vvoO

True, you can probably say that most of object.d belongs to the compiler. I wouldn't have any problem moving that.

>> As we move to more and more library-provided hooks and away from "compiler magic", this coupling will become less and less prevalent.
> 
> On the contrary, DMD will depend more and more on druntime as the magic is now in druntime and not in the dmd source code.

Not really. There is a confusion here about what is a dependency, and what is the interface. The agreed-upon interface between compiler and runtime is really the only thing that requires careful updates and breaks the CI. As long as the rest is independent, it can be done on one side or the other.

What I meant by the statement above is, the runtime is going to be deciding more of what actually happens instead of the compiler. When these decisions are moved out of the compiler and into the runtime (in the form of templates), the compiler becomes more streamlined and less crowded with "code generating code". The hooks become simpler and naturally more stable, because the place where you "play with" the functionality is in the library. This means you need to change those hooks less often, and breaking projects becomes less common.

A glaring example is the AA library. If the compiler simply lowered any Value[Key] to AssociativeArray!(Key, Value), and let the runtime define *everything*, when would you have to change the compiler again after that? But of course, until then, the compiler and AA runtime have to be altered in lock-step.

>> In fact, most of the changes that require both projects to be simultaneously to be updated are these magic-removing ones.
> 
> Yes and no. Whenever you want to update a library hooks (which are implementation-defined and not part of the specification), it's rather complicated to do with keeping all CIs happy.

Yes, exactly my point! The removal of magic means removal of the complicated hooks.

> 
>> If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler.
> 
> Good idea!

I think object.d can probably go to the compiler, but some stuff in there should probably be moved into a druntime-specific module. I'd have to look more deeply at the rt package to see what makes sense, but everything else should stay in druntime (core, gc).

-Steve

On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote:
>
> If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler.

Moving object.d to the dmd repository would be rather easy:

https://github.com/dlang/dmd/pull/8529
https://github.com/dlang/druntime/pull/2262

and already help a lot in decoupling both. Maybe that's a compromise that can be made?

On 01/08/2018 12:07 PM, Seb wrote:
> On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote:
>>
>> If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler.
> 
> Moving object.d to the dmd repository would be rather easy:
> 
> https://github.com/dlang/dmd/pull/8529
> https://github.com/dlang/druntime/pull/2262
> 
> and already help a lot in decoupling both. Maybe that's a compromise that can be made?

I think we're on to a winner now.

Just a matter now of figuring out if we should have an object.d module at all, and if we can split stuff out from it e.g. TypeInfo. There is of course other things like rt.* that could go with it.

On 7/31/2018 11:24 AM, Walter Bright wrote:
> On 7/27/2018 4:03 AM, Seb wrote:
>> This a thread to explore whether it would be feasible to do so.
> 
> Since DMD and Druntime require each other, it is the right thing to do.

Perhaps my judgement is premature. There are a lot of good points raised in this thread.

On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote:

> If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler.

I think this is right-on.  I don't see the solution yet, but I don't think it's just a matter of moving object.d.

Mike