BCD XML 2 D (Hi Gregor)

[Rémy Mouëza]

>BLS wrote:
>> Hi ,
>> A few month ago I am playing with the idea to create an Java2XML Tool in
>> order to use XML as intermediate language to translate Java into D. I found
>> an allready existing tool, but it only supports Java 1.3 and the generated
>> XML was not well formed. Anyway, Using ANTLR and the existing Java 1.5
>> Grammar I should be able to create a full working Java 1.5Parser . This
>> Parser will further enable me to create adequate XML representations....
>> XML to D ! At this point I am a little bit helpless and unexperienced, so I
>> would like to ask you, or somebody else of course , for advice, hints,links,
>> in other words help.
>> 
>> Bjoern
>> 
>> 

Last year, I have made a tool similar to Gregor's bcd. It was using GCCXML and
Python. I even ported part of the FLTK 1.5 library. I wasn't really satisfied
and was planning to make my own C++ header parser to do it again (some day),
using D this time but Gregor has been faster. 
Last november, I also used Peri Hankey's Language machine
(http://languagemachine.sf.net) to make a kind of C++ to D translator. I used
Peri D to D translator ( a proof of concept ) based on the same following idea:

>Most features of Java are supported by D in a somewhat direct fashion, 
>so I suspect that many parts of the XML->D translation will be somewhat 
>trivial.  Just write parser functions for each type of XML node that 
>outputs the appropriate D code, and since the structure is fairly 
>similar, much of it will probably work.

I mean, lots of C++ features are supported by D in a simpler and cleaner
fashion. Others are more difficult to translate. I just made some modifications
througout Peri's original translator front end to fool the back end. 
The parser could translate trivial code quite correctly but was making more
errors with longer code. It was convenient for speeding the rewrite of some C++
code into D. 
Yet, I have some trouble with the language machine: I'm so used to think
grammars as trees that I can't manage to start a binder from scratch using it.

Gregor said:
>But like I said, our projects, while they seem similar, are actually 
>fundamentally different (porting vs binding), so I'm not sure how much 
>help I can be.
>
>  - Gregor Richards

>From what I've experienced, I'd say :
- binding is relatively simpler than porting: there is less code to analyse but
this prevent to use some features or make these features difficult to use (
templates, cross-language porlymorphism, how to use D mixins in C++ ? ...).
- porting, if successfully achieved, don't limit the D programmer: all D
features can be used with the ported code, but there is more analysis involved,
some features have no direct equivalent in the target language ( Java
decorators, although we can do it using templates ) and there is no direct match
with the language library.

I was disappointed with my C++ to D translator because although it produced
syntactically correct code, the semantic was not translated at all. There had to
be a hand rewrite to make it work correctly. I didn't get any further. 

Peri Hankeys made a Java to D translator, modifying his D to D front end to make
it handle Java syntax. The main point now is to manage to match Java's library
with phobos or any runtime library. 
If your mind is not tied to grammar trees as mine, you may wish to join Peri's
project since the translation step is already done. Some Java expertise I don't
have is needed. The language machine is simpler to use than ANTLR, smaller ( but
you may not bother ), and is implemented in D ( actually gdc but dmd ports have
been reported ).

Gregor advice is fine too. 
>PS: Best advice: Just dive in and do it ^^

It would be wise to merge our efforts toward common goals, but we still should
have choice in the tool we use. Moreover, A Java to XML tool could be used by
people outside the D community.