Migrating D front end to D - post Dconf

[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.