View mode: basic / threaded / horizontal-split · Log in · Help
July 16, 2008
Porting D2 code to D1
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?
July 16, 2008
Re: Porting D2 code to D1
"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
July 16, 2008
Re: Porting D2 code to D1
"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.
July 16, 2008
Re: Porting D2 code to D1
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.
July 16, 2008
Re: Porting D2 code to D1
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
July 16, 2008
Re: Porting D2 code to D1
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){}
July 16, 2008
Re: Porting D2 code to D1
"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.
July 17, 2008
Re: Porting D2 code to D1
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.
July 17, 2008
Re: Porting D2 code to D1
"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.
July 17, 2008
Re: Porting D2 code to D1
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home