www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dual D2/D1 code base

reply Jason House <jason.james.house gmail.com> writes:
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?
May 15 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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.
May 15 2009
parent reply Jason House <jason.james.house gmail.com> writes:
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...
May 15 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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.
May 16 2009
parent reply Jason House <jason.james.house gmail.com> writes:
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.
May 16 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Jason House escribió:
 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.
Well, you can checkout Descent's source code and try playing with that if you want to. In fact, you could write a plugin for it. I'll give you some general steps needed to accomplish that: ICompilationUnit unit = ...; // this is your D file ASTParser parser = ASTParser.newParser(AST.D2); parser.setSource(unit); parser.setResolveBindings(true); // this is to get // symbol resolution CompilationUnit ast = (CompilationUnit) parser.createAST(null); Now we have the ast, doing ast.toString() should print it (without comments, for that you'd need to make something like the formatter implementation). You can traverse the ast using a visitor, or manually, modify it (for example adding modifiers) and then invoke toString() to get the new code. The only problems I see is a) D2 is not fully supported by Descent, and b) I don't know which rules are the ones to translate from D1 to D2 and backwards.
May 16 2009