BCD XML 2 D (Hi Gregor)

[Peri Hankey]

Rémy Mouëza wrote:
>>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.
> 
> 
>  

I describe the j2d translator at

   http://languagemachine.sourceforge.net/j2d.html

As I said in a comment on the dsource forum for the language machine:

<quote>
The src/j2d directory now contains a Makefile and rules for translating 
Java to the D language. The Makefile contains some apparatus for 
converting directory trees. None of this is very well documented as yet, 
and it is as yet unclear how the Java package system should relate to 
the D language module system. The j2d translator has been tried on the 
gnu classpath java, gnu, javax and vm package hierarchies (over 750k 
lines including comments), and appears to produce code that is 
syntactically acceptable to GDC-0.17 although almost certainly wrong in 
many details. However it is not possible to make much progress beyond 
this point without resolving the package/module relationship.
</quote>

The simplest way of dealing with this would be for the D language to 
have some way of explicitly modelling Java's package/class relationships.

It should be noted that what I have done does not as yet make any 
attempt to deal with java 1.5 extensions, which I have not yet studied 
in any detail.

I have shown that the language machine compiles with gdc-0.18 with one 
patch to the gdc code - see: thread for this message

    http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/1860

It was thanks to Remy's good work on the C++ translator that I did the 
same for Java. As I said elsewhere, the C++ project is bigger.

If anyone is interested to play with the j2d project, I am happy to be 
helpful - it would be really good to have others getting their heads 
round this beast.

On the xml front: if you have an effective translator from java to xml, 
the e4x extension to javascript makes it very easy to operate on 
javascript objects that directly represent xml objects. An equivalent 
extension to the D language would be interesting.

Personally I find xml and similar programmed tree-climbing exercises 
uncongenial by comparison with the grammatical transformation approach I 
am accustomed to.

It would also of course be possible to plug an xml output backend onto 
the j2d translator.

Regards to all
Peri

-- 
Peri Hankey                               mpah at thegreen.co.uk
http://languagemachine.sourceforge.net - The language machine