Dual D2/D1 code base

[Jason House]

Georg Wrede Wrote:

> Jason House wrote:
> > Georg Wrede Wrote:
> > 
> >> Jason House wrote:
> >>> I don't know what made me think of it, but could a feature very 
> >>> similar to Descent's compile-time view be used for generating D1
> >>> code from D2 code? It should allow striping of const, immutable,
> >>> nothrow, shared, and pure from D2 code with relative ease. It
> >>> obviously would not solve everything, but I think it could allow
> >>> Tango to use a single code base... Several Tango-based D1
> >>> libraries could then follow and support both D1 and D2.
> >>> 
> >>> Thoughts?
> >> I think changing storage classes, and the like, is the easy part.
> >> And writeln/writefln should be easy. But the rest is much harder.
> >> 
> > 
> > If I understand correctly, Descent's compile-time view pushed code
> > through the front end and then walks the resulting syntax tree to
> > regenerate the code. The ease of outputing alternate types really
> > depends on how the front end is implemented. I wouldn't expect
> > writeln vs. writefln to be solved by this. If this allows a simple
> > port of Tango to D2 to be converted back to D1, then that's all the
> > success I was hoping for. Note that doing this would bring a complete
> > standard library to both D1 and D2. Code written to use that subset
> > of functionality could also support D1 and D2 simultaneously. It does
> > limit some D2 features, but that's to be expected...
> 
> I'd imagine automatically porting D1 code to D2 should be way easier 
> than porting D2 code to D1. The first thing that comes to mind is when 
> somebyd has used some of the more advanced D2 features. Then, you'd 
> essentially either have to have a library that has most of the new 
> things written in D1, which you then call, or have the translator 
> generate this code. Both seem like enormous tasks.

Knowing where to add const, pure, shared, etc is far tougher than stripping it out.