Migrating D front end to D - post Dconf

[Paulo Pinto]

Am 11.05.2013 23:43, schrieb John Colvin:
> On Saturday, 11 May 2013 at 21:09:57 UTC, Jonathan M Davis wrote:
>> On Saturday, May 11, 2013 20:40:46 deadalnix wrote:
>>> 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.
>>
>> Yeah. And I'm stuck with the opposite problem at the moment. I have to
>> be able
>> to build old haskell code without updating it, but I don't have an older
>> version of ghc built currently, and getting a version old enough to
>> compile my
>> code has turned out to be a royal pain, because the old compiler won't
>> compile
>> with the new compiler. I don't even know if I'm going to be able to do
>> it.
>>
>> If you're always moving forward, you're okay, but if you have to deal
>> with
>> older code, then you quickly run into trouble if the compiler is
>> written in an
>> up-to-date version of the language that it's compiling. At least at this
>> point, if you needed something like 2.059 for some reason, you can
>> just grab
>> 2.059, compile it, and use it with your code. But if the compiler were
>> written
>> in D, and the version of D with 2.059 was not fully compatible with the
>> current version, then compiling 2.059 would become a nightmare.
>>
>> The situation between a normal program and the compiler is quite
>> different.
>> With a normal program, if your code isn't going to work with the current
>> compiler due to language or library changes, then you just grab an older
>> version of the compiler and use that (possibly upgrading your code
>> later if
>> you intend to maintain it long term). But if it's the compiler that
>> you're
>> trying to compile, then you're screwed by any language or library
>> changes that
>> affect the compiler, because it could very well become impossible to
>> compile
>> older versions of the compiler.
>>
>> Yes, keeping language and library changes to a minimum reduces the
>> problem,
>> but unless they're absolutely frozen, you risk problems. Even changes
>> with
>> high ROI (like making implicit fall-through on switch statements illegal)
>> could make building older compilers impossible.
>>
>> So, whatever we do with porting dmd to D, we need to be very careful.
>> We don't
>> want to lock ourselves in so that we can't make changes to the
>> language or
>> libraries even when we really need to, but we don't want to make it too
>> difficult to build older versions of the compiler for people who have
>> to either.
>> At the extreme, we could end up in a situation where you have to grab the
>> oldest version of the compiler which was written in C++, and then
>> build each
>> newer version of the compiler in turn until you get to the one that
>> you want.
>>
>> - Jonathan M Davis
>
> Can't this be eased with readily available binaries and cross compilation?
>
> E.g. We drop the C++ version in 2.7. You want DMD version 2.8.2. The
> minimum needed to compile 2.8.2 is 2.7.5:
>
> You can download a binary of 2.7.5 for any common system, cross compile
> 2.8.2 for your development system, viola! If there are binaries
> available for your development system, then it becomes almost trivial.
>
>
> Even if this wasn't possible for some reason, recursively building
> successive versions of the compiler is a completely automatable process.
> dmd+druntime+phobos compiles quickly enough that it's not a big problem.


I also don't understand the problem. This is how compilers get 
botstraped all the time.

You just use toolchain X to build toolchain X+1.

--
Paulo