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.
