Dual D2/D1 code base

[Ary Borenszweig]

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.