Is all this Invarient **** er... stuff, premature optimisation?

[Sean Kelly]

== Quote from Me Here (p9e883002 at sneakemail.com)'s article
> As I also mentioned, the descriptions I found (whilst looking for the
> above) of the new D2 language features
> drew me to it. Without thinking the the implications, it strikes me that a
> segregation of the compilers from
> the runtimes would allow the mating of the d2 compiler with the D1
> libraries?

See Tango, once again ;-)  In fact, as things stand, the same runtime could
be used for both 1.0 and 2.0 with a bit of work.  I haven't done this with
Tango mostly because I lack the time, but it's quite possible.  Alternately,
separate runtimes could be distributed and linked individually without
pulling in the bulk of an entire standard library.  The "Advanced
Configuration Guide" I liked previously for Tango shows how to do it.
This is simply more flexibility than the typical user cares about or wants
to deal with, so the sub-libraries are repackaged into a larger aggregate
library for the default distribution.  But if you build Tango locally you'll
find that the sub-libraries are still built behind the scenes.  From memory,
the names are:

libtango-rt-dmd.a : Tango runtime for DMD
libtango-rt-gdc.a : Tango runtime for GDC
libtango-gc-basic.a : Tango basic/default garbage collector
libtango-cc-tango.a : "common code" for the Tango standard library

The runtime contains only the compiler runtime code, the GC library
only the garbage collector, and the "common code" library contains
user-facing code which actually needs to be linked into every D
application--that being thread code and some error handling routines.
If you want to build on a system with no multithreading, for example,
simply toss stub out the 3 or so calls that this module exposes.

> The D1 libraries themselves would not use or benefit from the new D2
> language features but it would allow
> applications access to those features whilst retaining the stability of D1
> libraries.

Right.  The greatest obstacle here is the const design, since the meaning
of "const" is actually different between D 1.0 and 2.0, as well as the
requirement that even code in version blocks must be syntactically
correct.  Thus to support a toString method that returns a const string,
for example, the return value must be declared as an alias using a string
mixin.  Messy stuff, but it does work.


Sean