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.
