It may sound backwards, but I think it may be the best way to get things like Tango to move forward to D2.

Tango officially supports D1.  If it were to add D2 support, someone would have to port the D1 code to D2.  Then, with each change, a similar change must occur to the D2 code base.  From a maintenance standpoint, this really shouldn't be acceptable.

Since adding concepts such as const to D1 code in an automated fashion is essentially impossible, it seems the best approach is to convert D2 code into D1 code.  Programatically, it should be pretty easy to remove const-awareness.  That'd allow Tango to convert to D2 once and then (more or less) maintain one code base.

Maybe this would require a few special cases with D1-specific and D2-specific code, but I'd hope that wouldn't be very common.  I guess I have a few questions:

1. Besides const removal, what else must get done to convert D2 code to D1 code?
2. How can D version-specific code be mixed into a single code base?
3. Any thoughts on how to programatically do all the conversions?
4. Would this be enough for D1 library maintainers to move to D2?

"Jason House" wrote
> It may sound backwards, but I think it may be the best way to get things like Tango to move forward to D2.
>
> Tango officially supports D1.  If it were to add D2 support, someone would have to port the D1 code to D2.  Then, with each change, a similar change must occur to the D2 code base.  From a maintenance standpoint, this really shouldn't be acceptable.
>
> Since adding concepts such as const to D1 code in an automated fashion is essentially impossible, it seems the best approach is to convert D2 code into D1 code.  Programatically, it should be pretty easy to remove const-awareness.  That'd allow Tango to convert to D2 once and then (more or less) maintain one code base.
>
> Maybe this would require a few special cases with D1-specific and D2-specific code, but I'd hope that wouldn't be very common.  I guess I have a few questions:
>
> 1. Besides const removal, what else must get done to convert D2 code to D1
> code?
> 2. How can D version-specific code be mixed into a single code base?
> 3. Any thoughts on how to programatically do all the conversions?
> 4. Would this be enough for D1 library maintainers to move to D2?

As someone who has worked on trying to port Tango to D2 (as recently as last week), I believe there is more work to be done on D2 before anything like this is considered.

As of now, I have at least one critical bug that must be solved before Tango on D2 can be done:

http://d.puremagic.com/issues/show_bug.cgi?id=1644

Unless Tango actually builds on D2, there is no point at looking for ways to port changes back to D1 :)

-Steve

"Jason House" <jason.james.house@gmail.com> wrote in message news:g5ld20$1jbt$1@digitalmars.com...
> It may sound backwards, but I think it may be the best way to get things like Tango to move forward to D2.
>
> Tango officially supports D1.  If it were to add D2 support, someone would have to port the D1 code to D2.  Then, with each change, a similar change must occur to the D2 code base.  From a maintenance standpoint, this really shouldn't be acceptable.
>
> Since adding concepts such as const to D1 code in an automated fashion is essentially impossible, it seems the best approach is to convert D2 code into D1 code.  Programatically, it should be pretty easy to remove const-awareness.  That'd allow Tango to convert to D2 once and then (more or less) maintain one code base.
>
> Maybe this would require a few special cases with D1-specific and D2-specific code, but I'd hope that wouldn't be very common.  I guess I have a few questions:
>
> 1. Besides const removal, what else must get done to convert D2 code to D1 code?

Just removing const might not work if i.e. you have two methods that do the same thing, but one's const and one's non-const, though the converter might be able to pick those out.

Code that depends on D2's closure support would not work in D1, and you would have to do semantic analysis to know how to automatically convert from a D2 closure to a D1 struct.

Some minor syntactic differences, like "invariant {}" in D1 vs. "invariant() {}" in D2, as well as syntactic differences, like the new string literals in D2.

Numerical foreach, but that can be replaced by a simple for loop.

The (laughable) "enum" syntax for constants.

Struct postblits and dtors (and eventually ctors).

Stuff that depends on D2's overload sets would be very tricky to convert.

__traits just cannot be converted for most cases.

D2 allows you to overload opStar and opDot; both could simply be called manually as methods in the D1 code but you'd need semantic analysis to know when to.

> 2. How can D version-specific code be mixed into a single code base?

You almost answered it: mixins.  String mixins, that is.  It's somewhat frustrating that invariants for example must be handled something like this:

// Or would this be 'enum' in D2?  lol
const invariantBody = "{ some code blah blah blah }";

version(D2)
    mixin("invariant() " ~ invariantBody);
else
    mixin("invariant " ~ invariantBody);

It's times like this when you kind of wish for a "stupid" preprocessor.

> 3. Any thoughts on how to programatically do all the conversions?

Start with DParser, I'd guess.  Or one of the other D parser projects. You'd need semantic analysis for more than the simplest tasks, though.

> 4. Would this be enough for D1 library maintainers to move to D2?

Not for me, no.  I won't move to D2 until it's actually complete.

Steven Schveighoffer Wrote:

> As of now, I have at least one critical bug that must be solved before Tango on D2 can be done:
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=1644


Wow, I didn't realize anyone was still actively trying to port Tango to D2.  I notice that bug is nearly a year old and has had no activity on it (besides you adding how important it is to Tango).



> Unless Tango actually builds on D2, there is no point at looking for ways to port changes back to D1 :)

Knowing what kind of code can be converted from D1 to D2 and back to D1 isn't a bad exercise.  My interest really is in getting Tango to port to D2, but I'm sure there are other D1 library developers that are also holding back.

Jason House wrote:
> It may sound backwards, but I think it may be the best way to get things like Tango to move forward to D2.
> 
> Tango officially supports D1.  If it were to add D2 support, someone would have to port the D1 code to D2.  Then, with each change, a similar change must occur to the D2 code base.  From a maintenance standpoint, this really shouldn't be acceptable.
> 
> Since adding concepts such as const to D1 code in an automated fashion is essentially impossible, it seems the best approach is to convert D2 code into D1 code.  Programatically, it should be pretty easy to remove const-awareness.  That'd allow Tango to convert to D2 once and then (more or less) maintain one code base.
> 
> Maybe this would require a few special cases with D1-specific and D2-specific code, but I'd hope that wouldn't be very common.  I guess I have a few questions:
> 
> 1. Besides const removal, what else must get done to convert D2 code to D1 code?
> 2. How can D version-specific code be mixed into a single code base?
> 3. Any thoughts on how to programatically do all the conversions?
> 4. Would this be enough for D1 library maintainers to move to D2?

I was going to suggest using some sort of pre-processor but I think that is only a reasonable solution if everyone is on the same page that supporting both D1 and D2 is important.  In practice I think the current situation is more that there are devs who aren't interested in D2 and there are those who aren't interested in D1.  And neither group will be satisfied having to tart up the source code with pre-processor macros in order to make it work with the "other" version.

Also having to make the same code base compatible with both is increasingly going to mean crippling the D2 version, as D2 accumulates more and more tricks that are just impossible with D1. Like partial IFTI, which now works in D2 and is used heavily in Andrei's std.algorithm.

So I think probably forking is more realistic. That way the people who are wild about D2 are free to come up with solutions that make the most sense in D2 without having to worry about whether it will work in D1 or not.  Advances in D1 Tango can be ported forward as seems fit.  Maybe if you wait until Tango is officially 1.0 then the number of such changes will begin to taper off.  But I think it may be best to not put *too* much effort into making a D2 Tango "compatible" with D1 Tango.  Of course making it wildly different for no reason is also not a good idea.

--bb

Jarrett Billingsley Wrote:

> "Jason House" <jason.james.house@gmail.com> wrote in message news:g5ld20$1jbt$1@digitalmars.com...
> > It may sound backwards, but I think it may be the best way to get things like Tango to move forward to D2.
> >
> > Tango officially supports D1.  If it were to add D2 support, someone would have to port the D1 code to D2.  Then, with each change, a similar change must occur to the D2 code base.  From a maintenance standpoint, this really shouldn't be acceptable.
> >
> > Since adding concepts such as const to D1 code in an automated fashion is essentially impossible, it seems the best approach is to convert D2 code into D1 code.  Programatically, it should be pretty easy to remove const-awareness.  That'd allow Tango to convert to D2 once and then (more or less) maintain one code base.
> >
> > Maybe this would require a few special cases with D1-specific and D2-specific code, but I'd hope that wouldn't be very common.  I guess I have a few questions:
> >
> > 1. Besides const removal, what else must get done to convert D2 code to D1 code?

I was implicitly assuming something like a port of D1 code to D2 and then back to D2.  Obviously, D2 has cool functionality that would be tough to port to D1.  I probably should have also asked which subset of D2 can be easily converted to D1.  Postblits and such are obviously not portable to D1.


> Just removing const might not work if i.e. you have two methods that do the same thing, but one's const and one's non-const, though the converter might be able to pick those out.

Yeah, given a conflict, it's probably correct to go with the non-const version.



> Code that depends on D2's closure support would not work in D1, and you would have to do semantic analysis to know how to automatically convert from a D2 closure to a D1 struct.

In the clarified context, I think this is an ignorable difference.



> Some minor syntactic differences, like "invariant {}" in D1 vs. "invariant() {}" in D2, as well as syntactic differences, like the new string literals in D2.
>
> Numerical foreach, but that can be replaced by a simple for loop.
> 
> The (laughable) "enum" syntax for constants.

Those should be easy to convert over.



> Struct postblits and dtors (and eventually ctors).
> 
> Stuff that depends on D2's overload sets would be very tricky to convert.
> 
> __traits just cannot be converted for most cases.
> 
> D2 allows you to overload opStar and opDot; both could simply be called manually as methods in the D1 code but you'd need semantic analysis to know when to.


Those are probably all tougher to convert over, but are hopefully out of context.  I'm sure a previous D1 library maintainer wouldn't mind sticking with D1-like syntax :)



> > 2. How can D version-specific code be mixed into a single code base?
> 
> You almost answered it: mixins.  String mixins, that is.
> It's times like this when you kind of wish for a "stupid" preprocessor.

I can't imagine any library maintainer being willing to do that just for portability between D versions.  It'd be nice if D2 code could have something like version(d1){} and version(d2){} for this purpose.  That'd then allow the d2 compiler to ignore version(d1){} and allow the converter to strip out version(d2){}

"Jason House" <jason.james.house@gmail.com> wrote in message news:g5lib0$23ju$1@digitalmars.com...

> I can't imagine any library maintainer being willing to do that just for portability between D versions.  It'd be nice if D2 code could have something like version(d1){} and version(d2){} for this purpose.  That'd then allow the d2 compiler to ignore version(d1){} and allow the converter to strip out version(d2){}

I've always been dubious about using the version construct for various language versions.  It's great for program options, but since the stuff in the version block has to be syntactically legal, it makes it worthless for supporting multiple versions of D.

It's almost like another construct is needed.  I like what you're thinking but I don't know if using the version construct is the right way to do it.

Jarrett Billingsley Wrote:

> "Jason House" <jason.james.house@gmail.com> wrote in message news:g5lib0$23ju$1@digitalmars.com...
> 
> > I can't imagine any library maintainer being willing to do that just for portability between D versions.  It'd be nice if D2 code could have something like version(d1){} and version(d2){} for this purpose.  That'd then allow the d2 compiler to ignore version(d1){} and allow the converter to strip out version(d2){}
> 
> I've always been dubious about using the version construct for various language versions.  It's great for program options, but since the stuff in the version block has to be syntactically legal, it makes it worthless for supporting multiple versions of D.


Who says what's in version(d1) has to be legal D1 code? ;)  I'd vote that the code would still look like D2 code and would be converted in the same way as all other code.


> It's almost like another construct is needed.  I like what you're thinking but I don't know if using the version construct is the right way to do it.


If that construct is restricted to the converter (ie. ignore eliminate version(d2){}), I think nobody will complain.

"Jason House" <jason.james.house@gmail.com> wrote in message news:g5nhb4$r9d$1@digitalmars.com...
> Jarrett Billingsley Wrote:
>
>> "Jason House" <jason.james.house@gmail.com> wrote in message news:g5lib0$23ju$1@digitalmars.com...
>>
>> > I can't imagine any library maintainer being willing to do that just
>> > for
>> > portability between D versions.  It'd be nice if D2 code could have
>> > something like version(d1){} and version(d2){} for this purpose.
>> > That'd
>> > then allow the d2 compiler to ignore version(d1){} and allow the
>> > converter
>> > to strip out version(d2){}
>>
>> I've always been dubious about using the version construct for various
>> language versions.  It's great for program options, but since the stuff
>> in
>> the version block has to be syntactically legal, it makes it worthless
>> for
>> supporting multiple versions of D.
>
>
> Who says what's in version(d1) has to be legal D1 code? ;)  I'd vote that the code would still look like D2 code and would be converted in the same way as all other code.

Oh, oh, I see what you're saying now.  Those version blocks would just be dealt with by the converter, not the compiler.

Jarrett Billingsley Wrote:

> "Jason House" <jason.james.house@gmail.com> wrote in message news:g5nhb4$r9d$1@digitalmars.com...
> > Jarrett Billingsley Wrote:
> >
> >> "Jason House" <jason.james.house@gmail.com> wrote in message news:g5lib0$23ju$1@digitalmars.com...
> >>
> >> > I can't imagine any library maintainer being willing to do that just
> >> > for
> >> > portability between D versions.  It'd be nice if D2 code could have
> >> > something like version(d1){} and version(d2){} for this purpose.
> >> > That'd
> >> > then allow the d2 compiler to ignore version(d1){} and allow the
> >> > converter
> >> > to strip out version(d2){}
> >>
> >> I've always been dubious about using the version construct for various
> >> language versions.  It's great for program options, but since the stuff
> >> in
> >> the version block has to be syntactically legal, it makes it worthless
> >> for
> >> supporting multiple versions of D.
> >
> >
> > Who says what's in version(d1) has to be legal D1 code? ;)  I'd vote that the code would still look like D2 code and would be converted in the same way as all other code.
> 
> Oh, oh, I see what you're saying now.  Those version blocks would just be dealt with by the converter, not the compiler.
> 
> 

Done right, the code could compile as D2 code out of the box.  Using my ad hoc example, that'd require version=d2 to be included in the source.  The version(d1) would silently (and correctly) be ignored.  I don't know if this is best, but it certainly seems simple enough to do