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

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

Hmm, I would guess that gcj creates much the same GCCXML that Gregor use for his C/C++ header conversions, so maybe one possibility would be to build further on that?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Thanks Lars,
I will try to figure out what is possible. But I still prefer using ANTLR
because my bread and butter OS is M$. (and because I would like to translate
ANTLR, written in Java btw. ,into D)
Bjoern

Lars Ivar Igesund 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
> 
> 
> Hmm, I would guess that gcj creates much the same GCCXML that Gregor use for
> his C/C++ header conversions, so maybe one possibility would be to build
> further on that?
> 

No, GCCXML is sadly only an extension to the C++ parser.

 - Gregor Richards

Hi, Gregor,

> No, GCCXML is sadly only an extension to the C++ parser.
>
>   - Gregor Richards

Let us expect  for a moment that we allready have this  Java2XML Tool...
then the question is :
Is your XML2D Tool slick/flexible  enough (in the good old OOP sense) to
generate usefull D code ?

I am sorry about asking this question, but DSource is again not available.
I am interested in a Java2D translator because it will boost all
DWT/JFACE/DRAW2D efforts even if some manual work is still nessesary.
thanks in advance,
Bjoern

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
> 
> 

Honestly, I don't think I could help you much from a high-level view. With specifics, maybe, but since you're making a porter and I'm making a binder, they're actually quite different.  You won't have to mess with gobetween functions and the ilk, but I don't have to mess with any real code.

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.

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

PS: Best advice: Just dive in and do it ^^

BLS wrote:
> Hi, Gregor,
> 
> 
>>No, GCCXML is sadly only an extension to the C++ parser.
>>
>>  - Gregor Richards
> 
> 
> Let us expect  for a moment that we allready have this  Java2XML Tool...
> then the question is :
> Is your XML2D Tool slick/flexible  enough (in the good old OOP sense) to
> generate usefull D code ?
> 
> I am sorry about asking this question, but DSource is again not available.
> I am interested in a Java2D translator because it will boost all
> DWT/JFACE/DRAW2D efforts even if some manual work is still nessesary.
> thanks in advance,
> Bjoern
> 
> 
> 

Unfortunately, it's actually very tied to GCCXML's output format, which is a bit skrewy and therefore probably quite different from the XML you're generating.  It would be possible, but not useful, to make your XML-generator generate similar results, but bcd.gen makes bindings, not ports, so it wouldn't help much :)

 - Gregor Richards

>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.

Many thanks, Gregor
Though I hoped to get an more optimistic answere, your comments are highly
welcome. !!
I think I should create a Java 1.5 Lexer/Parser in D to give it a GO.
Instead of using XML as intermediate language I also can imagine to use
Terrence Parr s string templates to generate D Code without using an
intermediate step. ......................
Again thanks for your hints and comments.
Bjoern
PS
If you allow it I would like to ask you for some more information about your
project  .BCD.gen by email

Hi Remy,
you wrote :
> It would be wise to merge our efforts toward common goals, but we still
should
> have choice in the tool we use
A bit OFF TOPIC but this is one of the reasons why I am working on a Client/Server IDE which should enable us to work together in real time....

the language machine (simpler ?)
Maybe because of the several available examples and documents  ANTLR.
respectivre Terrence offers it  is (at least for me) easier to handle ANTLR
than the Language Machine.  So I will give it a try.. let us
see..................

Many Thanks for your comments, Remy.
Bjoern.






"Rémy Mouëza" <Rémy_member@pathlink.com> schreef in bericht news:e5q0tj$1p21$1@digitaldaemon.com...
> >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.
>
>
>