Smooth transition to D2 for Tango users?

[Denis Koroskin]

On Sun, 21 Sep 2008 19:55:48 +0400, Jason House  
<jason.james.house at gmail.com> wrote:

> Bruce Adams wrote:
>
>> Maybe I've misunderstood but what I thought was being asked for was for
>> the D1.0
>> language to be changed to accept D2.0 syntax and ignore it at some point
>> within blocks
>> marked as D1.0 versions.
>> This would mean that for a D1.0 compiler vendor to comply with the
>> standard the
>> D1.0 compiler would have to extended to parse D2.0.
>> A bit like asking a C compiler to ignore C++ class definitions.
>> Having D2.0 compilers accept D1.0 syntax in D1.0 version sections makes
>> more sense.
>
> I've proposed many things :)  My ultimate goal is for a smooth transition
> between D1.0 and D2.0.  For that to happen requires providing a path for
> Tango users and therefore Tango.  Obviously, that's not the only  
> important
> project, but it does have the largest user base.  I have to assume that a
> smooth transition for a project as large as Tango means it would exist  
> for
> other D1 projects.
>
> There are many ways to achieve that ultimate goal:
> 1. Backward compatibility (D2 parsing of all D1 code)
> 2. Forward compatibility (D1 parsing of a subset of D2 code)
> 3. version(D1), version(D2), with lightened parsing restrictions
> 4. Replace D's pre-processor
> 5. 3rd party pre-processor
> 6. D2 to D1 converter
>
> Below I tried to quickly make a list of pros and cons of each approach
> before having to run out the door.  I've probably missed an alternative  
> and
> many pros and cons.  I hope we can find an alternative, or combination of
> alternatives, that allow this to happen.
>
> #1: (backward compatibility)
> pros:
> * Enables a single D1 code base that compiles with either D dialect
> * Allows legacy code to compile and run without modification
> * Least effort for library maintainers
> cons:
> * Requires allowing exceptions to const/invariant rules
> * Requires Walter to commit to the approach
> * Walter has previously stated that he felt C was held back by backwards
>   compatibility.  It's unlikely that he'd support this approach.
>
> #2: (forward compatibility)
> pros:
> * Enables a single "D1" code base that compiles with either D dialect
> * Partial adoption makes other alternatives easier/simpler
> cons:
> * Allows D1 to look like D2 code
> * Requires Walter's to commit (at least partially) to the approach
>
> #3: (version(D1), version(D2))
> pros:
> * Easy to spot code intended for D1 and D2
> * Allows gradual phasing out of old D versions
> cons:
> * Can't wrap function prototypes in a version statement by themselves
> * Will cause massive code duplication and restrict code maintainability
> * Requires Walter to commit to one of two altrnatives:
>   * Parsing of alternate D dialects in one D dialect
>   * Ignoring of code within these special version blocks
> * Fraction of code that must be covered with version statements
>
> #4: (Replace D's pre-processor)
> pros:
> * Allows versioned function prototypes without duplicating all containing
>   code.
> cons:
> * Requires Walter to commit to this approach
> * Pre-processor is more C-like and Walter has already stated he's against
>   that
>
> #5: (3rd party pre-processor)
> pros:
> * Allows versioned function prototypes without duplicating all containing
>   code.
> * Unrestricted by D language design or Walter's choices
> cons:
> * Non-standard and unlikely to gain wide adoption
> * Makes use of library code tougher because of extra tools and  
> compilation
>   steps.  Could be alleviated by distributing 3 code bases.
>
> #6: (D2 to D1 converter)
> pros:
> * Enables a single D2 code base that compiles with either D dialect
> cons:
> * Impossible to downconvert all code automatically.
> * Must be combined with another approach

I would like to show some other aspect of the issue.

D has support for inline assembly. Different processors might have  
different assembly syntax and it is unlikely that every future D compiler  
would support all the syntaxes and recognize all command. Take a look at  
the tango.core.Atomic module. It contains x86 and x64 assembly  
instructions so far. However, it is likely that implementation for other  
platforms will be added soner or later (ARM, PowerPC and others). And they  
should somehow co-exist in one source code, like this:

bool cas(ref int value, int newValue, int oldValue) {
   version (X86) {
     asm {
       mov EDX, newValue;
       mov EAX, oldValue;
       mov ECX, value;
       lock;
       cmpxchg [ECX], EDX;
       setz AL;
     }
   } else version (PowerPC) {
     asm {
       // an implementaion using load-linked/store-conditional
     }
   }
}

(I am no expert in assembly, so I copied x86 code and left ppc code blank  
:)).

Current parsing rules state that the code in version block should be  
semantically correct, even if it is ignored. But since DMD knows basically  
nothing about those ll/sc op-codes, the code can't be placed in one source  
file, which is bad for maintainability.

Besides, I foresee "Smoth D2 to D3 transition", "Smooth D3 to D4  
transition" etc topics in future, so we should solve the issue once and  
for all.