Dual D2/D1 code base

[Georg Wrede]

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.