Migrating D front end to D - post Dconf

[Jonathan M Davis]

On Saturday, May 11, 2013 17:51:24 Walter Bright wrote:
> On 5/11/2013 2:09 PM, Jonathan M Davis wrote:
> > I have to be able
> > to build old haskell code without updating it,
> 
> I guess this is the crux of the matter. Why can't you update the source?

Well, in this particular case, it has to do with work on my master's thesis, 
and I have the code in various stages of completion and need to be able to 
look at exactly what it was doing at each of those stages for writing the 
actual paper. Messing with the code risks changing what it does, and it wasn't 
necessarily in a great state anyway given that I'm basically dealing with 
snapshots of the code over time, and not all of the snapshots are necessarily 
fully functional.

In the normal case, I'd definitely want to update my code, but I still might 
need to get the old code working before doing that so that I can be sure of 
how it works before changing it. Obviously, things like solid unit testing 
help with that, but if you're dealing with code that hasn't been updated in a 
while, it's not necessarily a straightforward task to update it, especially 
when it's in a language that you're less familiar with. It's even worse if 
it's code written by someone else entirely, and you're just trying to get it 
working (which isn't my current situation, but that's often the case when 
building old code).

Ultimately, I don't know how much we need to care about situations where 
people need to compile an old version of the compiler, and all they have is 
the new compiler. Much as its been causing me quite a bit of grief in haskell, 
for the vast majority of people, it's not likely to come up. But I think that 
it at least needs to be brought up so that it can be considered when deciding 
what we're doing with regards to porting the front-end to D. I think that main 
reason that C++ avoids the problem is that it's so rarely updated (which 
causes a whole different set of problems). And while we obviously want to 
minimize breakage caused by changes to the library, language, or just due to 
bugs, they _are_ going to have an effect with regards to building older 
compilers if the compiler itself is affected by them.

So, we might be better of restricting how much the compiler depends on - or we 
may decide that the workaround is to simply build the last C++ version of the 
compiler and then move forward from there. But I think that the issue should 
at least be raised.

- Jonathan M Davis