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.
