"David Nadlinger" <see@klickverbot.at> wrote in message news:mwkwqttkbdpmzvyviymq@forum.dlang.org...
> On Saturday, 11 May 2013 at 17:10:51 UTC, Daniel Murphy wrote:
>> If you decide that all later versions of the compiler must compile with
>> all
>> earlier versions of phobos, then those phobos modules are unable to
>> change.
>
> In (the rare) case of breaking changes, we could always work around them in the compiler source (depending on __VERSION__), rather than duplicating everything up-front.
>
> I believe *this* is the nice middle ground.
>
> David

That... doesn't sound very nice to me.  How much of phobos are we realistically going to need?

On Saturday, 11 May 2013 at 17:23:53 UTC, Daniel Murphy wrote:
> That... doesn't sound very nice to me.  How much of phobos are we
> realistically going to need?

All of it? Well, not quite, but large parts at least.

If we are going to stick to the C subset of the language, there is little point in translating it to D in the first place.

Of course, there will be some restrictions arising from the fact that the code base needs to work with D versions from a year back or so. But to me duplicating the whole standard library inside the compiler source seems like maintenance hell.

David

On 5/11/13 1:10 PM, Daniel Murphy wrote:
> Yes it's possible, but it seems like a really bad idea because:
> - Phobos is huge
> - Changes in phobos now have the potential to break the compiler

The flipside is:

- Phobos offers many amenities and opportunities for reuse
- Breakages in Phobos will be experienced early on a large system using them

I've talked about this with Simon Peyton-Jones who was unequivocal to assert that writing the Haskell compiler in Haskell has had enormous benefits in improving its quality.


Andrei

On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu wrote:
> - Breakages in Phobos will be experienced early on a large system using them
>
> I've talked about this with Simon Peyton-Jones who was unequivocal to assert that writing the Haskell compiler in Haskell has had enormous benefits in improving its quality.

This.

If we aren't confident that we can write and maintain a large real-world application in D just yet, we must pull the emergency brakes on the whole DDDMD effort, right now.

David

On Saturday, 11 May 2013 at 17:48:27 UTC, David Nadlinger wrote:
> […] the whole DDDMD effort […]

Whoops, must be a Freudian slip, revealing how much I'd like to see the D compiler being written in idiomatic D. ;)

David

"David Nadlinger" <see@klickverbot.at> wrote in message news:bwkwvbjdykrnsdezprls@forum.dlang.org...
> On Saturday, 11 May 2013 at 17:23:53 UTC, Daniel Murphy wrote:
>> That... doesn't sound very nice to me.  How much of phobos are we realistically going to need?
>
> All of it? Well, not quite, but large parts at least.
>
> If we are going to stick to the C subset of the language, there is little point in translating it to D in the first place.
>

I disagree.  Phobos is great, but there are thousands of things in the language itself that make it much more pleasant and effective than C++.

> Of course, there will be some restrictions arising from the fact that the code base needs to work with D versions from a year back or so. But to me duplicating the whole standard library inside the compiler source seems like maintenance hell.
>
> David

I agree.  But I was thinking much longer term compatibility, and a much smaller chunk of phobos.

"David Nadlinger" <see@klickverbot.at> wrote in message news:wynfxitcgpiggwemrmkx@forum.dlang.org...
> On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu wrote:
>> - Breakages in Phobos will be experienced early on a large system using them
>>
>> I've talked about this with Simon Peyton-Jones who was unequivocal to assert that writing the Haskell compiler in Haskell has had enormous benefits in improving its quality.
>
> This.
>
> If we aren't confident that we can write and maintain a large real-world application in D just yet, we must pull the emergency brakes on the whole DDDMD effort, right now.
>
> David

I'm confident in D, just not in phobos.  Even if phobos didn't exist, we'd still be in better shape using D than C++.  What exactly are we going to need from phobos?  sockets?  std.datetime? std.regex? std.container?

If we use them in the compiler, we effectively freeze them.  We can't use the new modules, because the old toolchains don't have them.  We can't fix old broken modules because the compiler depends on them.  If you add code to work around old modules being gone in later versions, you pretty much end up moving the source into the compiler after all.

If we only need to be able to compile with a version from 6 months ago, this is not a problem.  A year and it's still workable.  But two years?  Three? We can get something right here that gcc got so horribly wrong.

On 5/11/13 2:15 PM, Daniel Murphy wrote:
> "David Nadlinger"<see@klickverbot.at>  wrote in message
> news:wynfxitcgpiggwemrmkx@forum.dlang.org...
>> On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu wrote:
>>> - Breakages in Phobos will be experienced early on a large system using
>>> them
>>>
>>> I've talked about this with Simon Peyton-Jones who was unequivocal to
>>> assert that writing the Haskell compiler in Haskell has had enormous
>>> benefits in improving its quality.
>>
>> This.
>>
>> If we aren't confident that we can write and maintain a large real-world
>> application in D just yet, we must pull the emergency brakes on the whole
>> DDDMD effort, right now.
>>
>> David
>
> I'm confident in D, just not in phobos.  Even if phobos didn't exist, we'd
> still be in better shape using D than C++.  What exactly are we going to
> need from phobos?  sockets?  std.datetime? std.regex? std.container?
>
> If we use them in the compiler, we effectively freeze them.  We can't use
> the new modules, because the old toolchains don't have them.  We can't fix
> old broken modules because the compiler depends on them.  If you add code to
> work around old modules being gone in later versions, you pretty much end up
> moving the source into the compiler after all.
>
> If we only need to be able to compile with a version from 6 months ago, this
> is not a problem.  A year and it's still workable.  But two years?  Three?
> We can get something right here that gcc got so horribly wrong.

But you're exactly enumerating the problems any D user would face when we make breaking changes to Phobos.

Andrei

On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu wrote:
> On 5/11/13 1:10 PM, Daniel Murphy wrote:
>> Yes it's possible, but it seems like a really bad idea because:
>> - Phobos is huge
>> - Changes in phobos now have the potential to break the compiler
>
> The flipside is:
>
> - Phobos offers many amenities and opportunities for reuse
> - Breakages in Phobos will be experienced early on a large system using them
>
> I've talked about this with Simon Peyton-Jones who was unequivocal to assert that writing the Haskell compiler in Haskell has had enormous benefits in improving its quality.
>

Except that now, it is a pain to migrate old haskell stuff to newer haskelle stuff if you missed several compile release.

You ends up building recursively from the native version to the version you want.

We have an implementation in C+ that work, we got to ensure that whatever port of DMD is made in D, it does work with the C+ version.

On Saturday, 11 May 2013 at 18:15:22 UTC, Daniel Murphy wrote:
> If we use them in the compiler, we effectively freeze them.  We can't use
> the new modules, because the old toolchains don't have them.

Fair enough, but in such a case we could always add the parts of them we really need to the compiler source until the module is present in the last supported version. The critical difference of this scenario to your approach is that the extra maintenance burden is limited in time: The code is guaranteed to be removed again after (say) a year, and as Phobos stabilizes more and more, the total amount of such "compatibility" code will go down as well.

> We can't fix
> old broken modules because the compiler depends on them.

I don't see your point here:
  1) The same is true for any client code out there. The only difference is that we now directly experience what any D library writer out there has to go through anyway, if they want their code to work with multiple compiler releases.
  2) If a module is so broken that any "fix" would break all client code, we probably are not going to use it in the compiler anyway.

> If you add code to
> work around old modules being gone in later versions, you pretty much end up
> moving the source into the compiler after all.

Yes, but how often do you think this will happen? At the current point, the barrier for such changes should be quite high anyway. The amount of D2 code in the wild is already non-negligible and growing steadily.

> If we only need to be able to compile with a version from 6 months ago, this
> is not a problem.  A year and it's still workable.  But two years?  Three?
> We can get something right here that gcc got so horribly wrong.

Care to elaborate on that?

David