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