On 7/28/14, 12:13 PM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:lr64ah$1akc$1@digitalmars.com...
>
>> Agreed. Conversely we'd be hamstringing ourselves by essentially
>> making D a poorer choice for implementing dmd than any other languages.
>
> This doesn't make any sense.

Well, if quoted without the surrounding context...

Andrei

"Andrei Alexandrescu"  wrote in message news:lr6c5j$1h13$1@digitalmars.com...

> The way I see some of these liabilities is as dogfooding. For example if slow compile times and code bloat become a problem with ddmd they are also a problem with other large D programs, and it's good to have an extra incentive to fix them.

Hopefully the desire to see phobos used in ddmd will provide the needed motivation to fix these issue so it's suitable for use.

I'm quite happy with our dog food but I'm not so sure about the dog house, dog toys and dog shampoo.  Puppy steps. 

On Tue, Jul 29, 2014 at 05:02:26AM +1000, Daniel Murphy via Digitalmars-d wrote:
> "H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.124.1406572776.16021.digitalmars-d@puremagic.com...
> 
> >I see this as a good thing, actually. Not that I think it's good to increase compile time and binary bloat, but that when this happens, we will have very strong incentives to do something about it, that will drive us to do whatever it takes for Phobos to *not* get in the way of fast compile times and to *not* introduce tons of template bloat. The end result will be a far better quality Phobos than we might ever achieve otherwise, since external D codebases wouldn't be as strong an incentive as the compiler itself would.
> 
> I do not see it that way.  Once phobos quality is acceptable, then we can think about using it in dmd.  As much as I want phobos to be as good as possible, this cannot in any way come at the expense of the compiler's quality.

It depends on how we do the transition. If we replace dmd with ddmd first, then we'll run into problems with Phobos adoption, because we may discover that using Phobos causes (d)dmd to be unacceptably slow / bloated / etc., which means it becomes a disincentive to use Phobos in ddmd.

But another way to approach it, is to do Phobos integration first, while we still have the current C++ code. We may discover that ddmd becomes unacceptably slow -- but since all of us want to make D self-hosted, this is great incentive for improving Phobos so that ddmd is *not* slow. While we work on fixing Phobos, we still have the current C++ dmd to serve user needs. Then when Phobos is finally no longer slow/bloated in ddmd, we can transition to ddmd and have a compiler on par or even better than the C++ dmd.


> >Perhaps the solution is to get more people involved in this review? Y'know, increase the bus factor and everything.
> 
> Do you mean dmd contributors should be reviewing phobos pulls instead of working on dmd?

Well, I don't think anyone is going to *force* you to do that, this being a volunteer project and everything. :-) What about recruiting new contributors who can help out?


> >Would it be too unrealistic to set things up so that ddmd bootstraps itself with a *previous* release of Phobos, and then compile itself again with the latest Phobos git HEAD? (And by this I mean that `make -f posix.mak` will actually run through this bootstrap process, so that if something breaks, it will be very obvious in the autotester and we wouldn't pull whatever PR it is that caused the breakage.) This would ensure that whatever we do, ddmd won't become uncompilable with a previous release of itself, but will be effectively written in a prior version of D (or ideally, in the common subset of D between the two releases, or N releases if we decide to do that).
> 
> Yes, this one can be solved somewhat by improving test infrastructure. But it will tie the parts of phobos that dmd uses to dmd's release cycle.
> 
> eg if we add a new built-in attribute, it can't be used in phobos until the last compiler that doesn't support it is no longer supported for building dmd.  Same for every compiler patch.

Not necessarily. If the compiler doesn't use the parts of Phobos that has the new attribute, then it's not a problem.

Another solution (albeit uglier) is to use version(...) in Phobos to
suppress certain new features if the current compiler is known not to
support it:

	static if (__VERSION__ <= 2099L)
	{
		// This is the old version compatible with 2.099 or
		// earlier.
		auto myPhobosFunc(R)(R range) /* don't use @newAttribute */
		{
			...
		}
	}
	else
	{
		// This is the new version that requires 2.100 or
		// higher.
		auto myPhobosFunc(R)(R range) @newAttribute
		{
			...
		}
	}

The first stage of bootstrapping will use myPhobosFunc without @newAttribute, but when compiling the second stage (final) compiler, it will use myPhobosFunc with @newAttribute, because the first stage compiler now understands what it is.


> It would also be nice to keep compatibility further back than a single dmd release.  This would make things harder.

I think this should be possible using static if (__VERSION__ ...).


T

-- 
This sentence is false.

On Monday, 28 July 2014 at 22:45:51 UTC, H. S. Teoh via Digitalmars-d wrote:

> But another way to approach it, is to do Phobos integration first, while we still have the current C++ code.

I would point out that the way that ddmd is being done is to automatically translate dmd from C++ to D, so everything has to be done on the C++ end until we've actually switched it over to D permanently. That means that we can't take advantage of any of D's features (be they in the language or the standard library) until we've actually fully switched the compiler to D. So, Phobos integration _can't_ come first.

- Jonathan M Davis

On 28 July 2014 21:34, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 7/28/14, 11:24 AM, Daniel Murphy wrote:
>>
>> "Andrei Alexandrescu"  wrote in message news:lr6395$19r7$1@digitalmars.com...
>>
>>> There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei
>>
>>
>> This is true, but my main concern is the quality of the compiler source.
>>
>> My main concerns are: (not in order)
>> - Compile time
>> - Binary bloat
>> - Reduced scrutiny of code that is used in the compiler - I review every
>> single compiler patch, but I do not have time to do that for phobos too
>> - The compiler must build with the last release, and with HEAD.  HEAD
>> phobos only needs to build with HEAD.
>> - Some other things.
>
>
> The way I see some of these liabilities is as dogfooding. For example if slow compile times and code bloat become a problem with ddmd they are also a problem with other large D programs, and it's good to have an extra incentive to fix them.
>

Indeed, before this topic gets derailed any further. Do you have any thoughts on the initial post?

Iain.

On 7/28/14, 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
> Indeed, before this topic gets derailed any further. Do you have any
> thoughts on the initial post?

I don't understand the question. -- Andrei

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.130.1406587551.16021.digitalmars-d@puremagic.com...

> It depends on how we do the transition. If we replace dmd with ddmd
> first, then we'll run into problems with Phobos adoption, because we may
> discover that using Phobos causes (d)dmd to be unacceptably slow /
> bloated / etc., which means it becomes a disincentive to use Phobos in
> ddmd.

There is no if, this is exactly how it is going to happen.  Phobos will not be used in ddmd until after the transition.

> But another way to approach it, is to do Phobos integration first, while
> we still have the current C++ code. We may discover that ddmd becomes
> unacceptably slow -- but since all of us want to make D self-hosted,
> this is great incentive for improving Phobos so that ddmd is *not* slow.
> While we work on fixing Phobos, we still have the current C++ dmd to
> serve user needs. Then when Phobos is finally no longer slow/bloated in
> ddmd, we can transition to ddmd and have a compiler on par or even
> better than the C++ dmd.

No.  If you want to improve phobos, make phobos quality a blocker for your own projects, don't screw over ddmd.

> Well, I don't think anyone is going to *force* you to do that, this
> being a volunteer project and everything. :-) What about recruiting new
> contributors who can help out?

Again, let's not make a phobos problem a dmd problem.

> Not necessarily. If the compiler doesn't use the parts of Phobos that
> has the new attribute, then it's not a problem.

Maybe, but I'm not so sure it will be that easy.

> Another solution (albeit uglier) is to use version(...) in Phobos to
> suppress certain new features if the current compiler is known not to
> support it:

That's somewhere between horrific and unacceptable.  It's just not worth it.

> I think this should be possible using static if (__VERSION__ ...).

Possible but not worthwhile.

On 29 July 2014 07:28, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 7/28/14, 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
>>
>> Indeed, before this topic gets derailed any further. Do you have any thoughts on the initial post?
>
>
> I don't understand the question. -- Andrei
>

I didn't start this thread to talk about ddmd. :o)