Migrating dmd to D?

[H. S. Teoh]

On Fri, Mar 01, 2013 at 05:44:52PM +0100, js.mdnq wrote:
> On Friday, 1 March 2013 at 10:36:04 UTC, Jonathan M Davis wrote:
[...]
> >I don't really care about the license, but I can definitely say that
> >part of me finds the idea of having a compiler compiling itself to be
> >a bad idea, much is compiler folks love to do that. Recently, I had
> >some older haskell code that I needed to compile, but it followed the
> >previous haskell standard, and I couldn't get the current compiler to
> >compile it even in compatability mode.  So, I tried to compile an
> >older version of the compiler from before the new standard, and it
> >had exactly the same problems that my code did, because it was
> >written in haskell using the older standard. So, I had to give up on
> >being able to compile my code, because I couldn't get my hands on an
> >old enough version of the compiler. If they'd just written it in
> >C/C++, then I wouldn't have had that problem.
> >
> >I know that it's generally touted as a great idea for a language to
> >compile itself, and I'm sure that it would be great to be able to use
> >D's features in the compiler, but the circular dependency that that
> >causes is a definite negative IMHO.
> >
> >- Jonathan M Davis
> 
> There is no problem with circular dependencies as long as the
> language spec has a fixed subset that the compiler is written in.
> The reason is that any future version then can compile the compiler
> source because the future versions all support the subset.
> 
> This is why it is so important to get the fixed language subset down
> because it will the core language features and can't be changed
> without causing regressive dependencies.
> 
> Any evolution of the D compiler will compile it's own compiler
> source as long as it properly implements the D language subset. This
> subset also has to be a subset of the current dmd language
> implementation to bootstrap from.

+1.

Another reason I keep saying that we need to write the D compiler in a
fixed subset of D. There are many advantages to this. For one, it will
solve the GDC situation -- we can just ship the last C++ version of DMD
with GDC (outdated but it will correctly compile the newest D compiler),
then it can be used to compile the D version of the compiler.

Then there's the above point, that if the last C++ version of DMD is
capable of compiling the latest D version of DMD, then we won't run into
the situation where you can't compile anything unless you checkout
successive versions of DMD just to be able to compile the next one.

Restricting DMD to a fixed subset of D also means that it will not be
vulnerable to subtle bugs caused by later breaking changes to the
language. Let's just face it, the current version of D is far from
breaking changes, even if we're trying our best to stabilize it. Using a
fixed subset of D to write the compiler ensures that all versions of the
compiler are compilable by all other versions of it, which comes in very
useful when you end up in Jonathan's situation above.


T

-- 
One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion