okay,
the Java Parser, the Java AST Parser and very basic work on the D Emitter
are done.

DEmitter > A class that can take an ANTLR Java AST and produce formatted
 D Java code from it

I guess the string, array and modifiers stuff will be tricky.

anyway, first things first :the following table has to be transformed : is somebody out there who is kind enough to give me advice regarding the modifieres stuff : well translationg the table to D is also highly welcome <g>

  tokenNames[POST_INC]="++";
  tokenNames[POST_DEC]="--";
  tokenNames[UNARY_MINUS]="-";
  tokenNames[UNARY_PLUS]="+";
  tokenNames[STAR]="*";
  tokenNames[ASSIGN]="=";
  tokenNames[PLUS_ASSIGN]="+=";
  tokenNames[MINUS_ASSIGN]="-=";
  tokenNames[STAR_ASSIGN]="*=";
  tokenNames[DIV_ASSIGN]="/=";
  tokenNames[MOD_ASSIGN]="%=";
  tokenNames[SR_ASSIGN]=">>=";
  tokenNames[BSR_ASSIGN]=">>>=";
  tokenNames[SL_ASSIGN]="<<=";
  tokenNames[BAND_ASSIGN]="&=";
  tokenNames[BXOR_ASSIGN]="^=";
  tokenNames[BOR_ASSIGN]="|=";
  tokenNames[QUESTION]="?";
  tokenNames[LOR]="||";
  tokenNames[LAND]="&&";
  tokenNames[BOR]="|";
  tokenNames[BXOR]="^";
  tokenNames[BAND]="&";
  tokenNames[NOT_EQUAL]="!=";
  tokenNames[EQUAL]="==";
  tokenNames[LT]="<";
  tokenNames[GT]=">";
  tokenNames[LE]="<=";
  tokenNames[GE]=">=";
  tokenNames[SL]="<<";
  tokenNames[SR]=">>";
  tokenNames[BSR]=">>>";
  tokenNames[PLUS]="+";
  tokenNames[MINUS]="-";
  tokenNames[DIV]="/";
  tokenNames[MOD]="%";
  tokenNames[INC]="++";
  tokenNames[DEC]="--";
  tokenNames[BNOT]="~";
  tokenNames[LNOT]="!";
  tokenNames[FINAL]="final";
  tokenNames[ABSTRACT]="abstract";
  tokenNames[LITERAL_package]="package";
  tokenNames[LITERAL_import]="import";
  tokenNames[LITERAL_void]="void";
  tokenNames[LITERAL_boolean]="boolean";
  tokenNames[LITERAL_byte]="byte";
  tokenNames[LITERAL_char]="char";
  tokenNames[LITERAL_short]="short";
  tokenNames[LITERAL_int]="int";
  tokenNames[LITERAL_float]="float";
  tokenNames[LITERAL_long]="long";
  tokenNames[LITERAL_double]="double";
  tokenNames[LITERAL_private]="private";
  tokenNames[LITERAL_public]="public";
  tokenNames[LITERAL_protected]="protected";
  tokenNames[LITERAL_static]="static";
  tokenNames[LITERAL_transient]="transient";
  tokenNames[LITERAL_native]="native";
  tokenNames[LITERAL_threadsafe]="threadsafe";
  tokenNames[LITERAL_synchronized]="synchronized";
  tokenNames[LITERAL_volatile]="volatile";
  tokenNames[LITERAL_class]="class";
  tokenNames[LITERAL_extends]="extends";
  tokenNames[LITERAL_interface]="interface";
  tokenNames[LITERAL_implements]="implements";
  tokenNames[LITERAL_throws]="throws";
  tokenNames[LITERAL_if]="if";
  tokenNames[LITERAL_else]="else";
  tokenNames[LITERAL_for]="for";
  tokenNames[LITERAL_while]="while";
  tokenNames[LITERAL_do]="do";
  tokenNames[LITERAL_break]="break";
  tokenNames[LITERAL_continue]="continue";
  tokenNames[LITERAL_return]="return";
  tokenNames[LITERAL_switch]="switch";
  tokenNames[LITERAL_throw]="throw";
  tokenNames[LITERAL_case]="case";
  tokenNames[LITERAL_default]="default";
  tokenNames[LITERAL_try]="try";
  tokenNames[LITERAL_finally]="finally";
  tokenNames[LITERAL_catch]="catch";
  tokenNames[LITERAL_instanceof]="instanceof";
  tokenNames[LITERAL_this]="this";
  tokenNames[LITERAL_super]="super";
  tokenNames[LITERAL_true]="true";
  tokenNames[LITERAL_false]="false";
  tokenNames[LITERAL_null]="null";
  tokenNames[LITERAL_new]="new";

thanks bjoern

What does this table mean?

tokenNames[POST_INC]="++";
tokenNames[Java symbol] = "D translation"
??

The main problem is, that the operator cannot be mapped 1o1.
The plus in Java can concatenate two strings, in D the '~' is used.
Same for += and ~=.
So if the parser do not know the types of the + operands, a solution can
be to make every + operation to a D function call.

java:
a += b;
c = a + b;
D:
AddAssign( a, b );
c = Add( a, b );

And AddAssign, Add are overloaded with various types:
Add( char[], ... )
Add( int, int )
Add( long, long )
...

Java:
a instanceof ClassA
D:
((cast(ClassA)a) !is null )

Hi Frank,
I am sorry. My previous problem discription was a piece of ...., I was a bit
in a hurry, so give me a second chance.
How to translate the following Java class/method/variable modifieres into D.

public, protected, private
do the D counterparts have the same scope ?.

static, final (or a combination of them)
...especially, when in use for Java classes.

synchronized, volatile (the thread thing).

any hint, tip, etc. is welcome.Thanks bjoern
PS ----------------------------------------
I know about the problems you are talking about in your previous msg.. I
think I should be able to solve them (better > some of them) because walking
the AST back or doing AST lookaheads is possible.  I am also able to
visualize the AST, which is indeed, a great help.

"Frank Benoit" <keinfarbton@nospam.xyz> schreef in bericht news:e9ovom$15sb$1@digitaldaemon.com...
> What does this table mean?
>
> tokenNames[POST_INC]="++";
> tokenNames[Java symbol] = "D translation"
> ??
>
> The main problem is, that the operator cannot be mapped 1o1.
> The plus in Java can concatenate two strings, in D the '~' is used.
> Same for += and ~=.
> So if the parser do not know the types of the + operands, a solution can
> be to make every + operation to a D function call.
>
> java:
> a += b;
> c = a + b;
> D:
> AddAssign( a, b );
> c = Add( a, b );
>
> And AddAssign, Add are overloaded with various types:
> Add( char[], ... )
> Add( int, int )
> Add( long, long )
> ...
>
> Java:
> a instanceof ClassA
> D:
> ((cast(ClassA)a) !is null )
>
>
>
>
>

BLS wrote:
> okay,
> the Java Parser, the Java AST Parser and very basic work on the D Emitter
> are done.
> 
> DEmitter > A class that can take an ANTLR Java AST and produce formatted
>  D Java code from it
> 
> I guess the string, array and modifiers stuff will be tricky.

Arrays will be the trickiest - they're objects in Java, but something completely different in D (better, but totally not-compatible). While it may seem that it can be easily be solved with a template Array object, it can't for the simple reason, that a Derived[] is also a Base[] (but you can't put non-Derived object inside), and that's just not practically doable. You'd have to list all superclasses/interfaces for each array class that appears..

I can't think of a reasonable implementation that would mimic the arrays in Java, so I guess the only choice is to have a single implementation (non-templated) which keeps the element class type at runtime and checks on writes. That's bad, because the information on types of arrays is lost in source..


> anyway, first things first :the following table has to be transformed :
> is somebody out there who is kind enough to give me advice regarding the
> modifieres stuff : well translationg the table to D is also highly welcome
> <g>

>   tokenNames[FINAL]="final";

becomes either final (for classes and methods) or const (for variables)

>   tokenNames[LITERAL_package]="package";

Ideally, you will take several classes and place them into one module; that way, their FQNs (full names) stay about the same. However, there is a problem there - you can't have both modules "foo.bar" and "foo.bar.baz" in D. But, since the packages do not form a hierarchy in Java (foo, foo.bar and foo.baz are as distinct as kuku, abc.def and qwe.dfg), you can rename them to something like foo.bar and foo_bar.baz for the above case.

>   tokenNames[LITERAL_import]="import";

This will be tricky; you can either import
a) a normal class (java.util.HashMap),
b) an inner class (java.util.Map.Entry),
c) all members of a package (java.util.*),

For the first two cases, you can also import
d) one static member (import static java.lang.Math.PI) or
e) all static members of a class (import static java.lang.Math.*)

Assuming you do convert packages into modules (so a module contains all classes from a Java package), those become

a)
static import java.util;
alias java.util.HashMap HashMap;

b)
static import java.util;
alias java.util.Map.Entry Entry;

c)
private import java.util; // private now optional

d)
static import java.lang;
alias java.lang.Math.PI PI;

e)
static import java.lang;
alias java.lang.Math.sin sin;
alias java.lang.Math.cos cos;
etc.

To get the last case just right, some analysis of class contents will have to be made...


>   tokenNames[LITERAL_private]="private";

this is still private, though it doesn't have the same effect - in Java private really means private, while in D it's module-private.

>   tokenNames[LITERAL_transient]="transient";

this is used for serialization only, can be dropped (and there is no equivalent in D)

>   tokenNames[LITERAL_native]="native";

luckily, no longer needed :) unluckily, you have to get the code for such a function from somewhere else, and it's probably C/C++

>   tokenNames[LITERAL_threadsafe]="threadsafe";

never heard of this..

>   tokenNames[LITERAL_synchronized]="synchronized";

when used with an expression, it's the same as in D, but can also be a modifier for functions. With non-static methods,

synchronized func()
{
}

becomes

func()
{
    synchronized(this) {
    }
}

With static methods, its synchronized(ClassName.class) in Java, I'm not sure whether something similar can be used in D (is TypeInfo an object or a struct?)

>   tokenNames[LITERAL_volatile]="volatile";

There are no volatile variables in D, so this is quite tricky; theoretically, you'd have to wrap each access of such a variable into a volatile statement...

>   tokenNames[LITERAL_throws]="throws";

These can be dropped (or even better - converted to DDoc ;)

>   tokenNames[LITERAL_case]="case";
>   tokenNames[LITERAL_default]="default";

Note that there's an implicit "default: assert(0)" in D, but an implicit "default: break" in Java.

>   tokenNames[LITERAL_instanceof]="instanceof";

expr instanceof ClassName
becomes
(cast(ClassName)expr)

No need to compare it to null, as it will be automatically done.

>   tokenNames[LITERAL_this]="this";

For inner classes, you can have an expressions OuterClass.this; no such thing in D..

>   tokenNames[LITERAL_new]="new";

In Java, you can write "new Foo().method()", in D it must be "(new Foo).method()".

Hope that helps :)


xs0

Thanks, a lot of usefull information. I think I should open a dsource project, to publish the Java parser, the java tree parser, a few helper classes and the D Emitter (which is not worth its name at the moment, but using your and Franks info should enable me to make some progress)

The D Emitter(in fact a slightly modified Java Emitter) is beside, quit easy
to understand.
 The very optimistic goal is of course to have a D Emitter which is able to
create perfect translations. A more realistic goal for the near future is to
translate as much as possible, and to extensively comment the untranslated
parts including translation suggestion.

Bjoern

"xs0" <xs0@xs0.com> schreef in bericht news:e9q7n9$2lu0$1@digitaldaemon.com...
> BLS wrote:
> > okay,
> > the Java Parser, the Java AST Parser and very basic work on the D
Emitter
> > are done.
> >
> > DEmitter > A class that can take an ANTLR Java AST and produce formatted
> >  D Java code from it
> >
> > I guess the string, array and modifiers stuff will be tricky.
>
> Arrays will be the trickiest - they're objects in Java, but something completely different in D (better, but totally not-compatible). While it may seem that it can be easily be solved with a template Array object, it can't for the simple reason, that a Derived[] is also a Base[] (but you can't put non-Derived object inside), and that's just not practically doable. You'd have to list all superclasses/interfaces for each array class that appears..
>
> I can't think of a reasonable implementation that would mimic the arrays in Java, so I guess the only choice is to have a single implementation (non-templated) which keeps the element class type at runtime and checks on writes. That's bad, because the information on types of arrays is lost in source..
>
>
> > anyway, first things first :the following table has to be transformed : is somebody out there who is kind enough to give me advice regarding the modifieres stuff : well translationg the table to D is also highly
welcome
> > <g>
>
> >   tokenNames[FINAL]="final";
>
> becomes either final (for classes and methods) or const (for variables)
>
> >   tokenNames[LITERAL_package]="package";
>
> Ideally, you will take several classes and place them into one module; that way, their FQNs (full names) stay about the same. However, there is a problem there - you can't have both modules "foo.bar" and "foo.bar.baz" in D. But, since the packages do not form a hierarchy in Java (foo, foo.bar and foo.baz are as distinct as kuku, abc.def and qwe.dfg), you can rename them to something like foo.bar and foo_bar.baz for the above case.
>
> >   tokenNames[LITERAL_import]="import";
>
> This will be tricky; you can either import
> a) a normal class (java.util.HashMap),
> b) an inner class (java.util.Map.Entry),
> c) all members of a package (java.util.*),
>
> For the first two cases, you can also import
> d) one static member (import static java.lang.Math.PI) or
> e) all static members of a class (import static java.lang.Math.*)
>
> Assuming you do convert packages into modules (so a module contains all classes from a Java package), those become
>
> a)
> static import java.util;
> alias java.util.HashMap HashMap;
>
> b)
> static import java.util;
> alias java.util.Map.Entry Entry;
>
> c)
> private import java.util; // private now optional
>
> d)
> static import java.lang;
> alias java.lang.Math.PI PI;
>
> e)
> static import java.lang;
> alias java.lang.Math.sin sin;
> alias java.lang.Math.cos cos;
> etc.
>
> To get the last case just right, some analysis of class contents will have to be made...
>
>
> >   tokenNames[LITERAL_private]="private";
>
> this is still private, though it doesn't have the same effect - in Java private really means private, while in D it's module-private.
>
> >   tokenNames[LITERAL_transient]="transient";
>
> this is used for serialization only, can be dropped (and there is no
> equivalent in D)
>
> >   tokenNames[LITERAL_native]="native";
>
> luckily, no longer needed :) unluckily, you have to get the code for such a function from somewhere else, and it's probably C/C++
>
> >   tokenNames[LITERAL_threadsafe]="threadsafe";
>
> never heard of this..
>
> >   tokenNames[LITERAL_synchronized]="synchronized";
>
> when used with an expression, it's the same as in D, but can also be a modifier for functions. With non-static methods,
>
> synchronized func()
> {
> }
>
> becomes
>
> func()
> {
>      synchronized(this) {
>      }
> }
>
> With static methods, its synchronized(ClassName.class) in Java, I'm not
> sure whether something similar can be used in D (is TypeInfo an object
> or a struct?)
>
> >   tokenNames[LITERAL_volatile]="volatile";
>
> There are no volatile variables in D, so this is quite tricky; theoretically, you'd have to wrap each access of such a variable into a volatile statement...
>
> >   tokenNames[LITERAL_throws]="throws";
>
> These can be dropped (or even better - converted to DDoc ;)
>
> >   tokenNames[LITERAL_case]="case";
> >   tokenNames[LITERAL_default]="default";
>
> Note that there's an implicit "default: assert(0)" in D, but an implicit
> "default: break" in Java.
>
> >   tokenNames[LITERAL_instanceof]="instanceof";
>
> expr instanceof ClassName
> becomes
> (cast(ClassName)expr)
>
> No need to compare it to null, as it will be automatically done.
>
> >   tokenNames[LITERAL_this]="this";
>
> For inner classes, you can have an expressions OuterClass.this; no such thing in D..
>
> >   tokenNames[LITERAL_new]="new";
>
> In Java, you can write "new Foo().method()", in D it must be "(new
> Foo).method()".
>
> Hope that helps :)
>
>
> xs0

BLS wrote:

Uh, these names are tricky.
When I saw "Java2D" my first thought was that is has something to deal with 2D
graphics in Java <g>.

-- 

good point, you are right, I bettter named it Antlr treewalker based Java to
D Translator. ?!
Bjoern

"Andrei Khropov" <andkhropov@nospam_mtu-net.ru> schreef in bericht news:e9qf6c$h5$1@digitaldaemon.com...
> BLS wrote:
>
> Uh, these names are tricky.
> When I saw "Java2D" my first thought was that is has something to deal
with 2D
> graphics in Java <g>.
>
> -- 
>

BLS wrote:

> good point, you are right, I bettter named it Antlr treewalker based Java to
> D Translator. ?!
> Bjoern
> 

Nothing against it, actually. It's the most natural name for this kind of stuff. Just my chatter.

-- 

Is this project online accessible?

I need an other  week. The current parser, treeparser ....are based on Java 1.3.  But I want the Java 5 thing on dsolurce.org (allready contacted Brad)

Bjoern

"Frank Benoit" <keinfarbton@nospam.xyz> schreef in bericht news:e9vu3v$1anc$1@digitaldaemon.com...
> Is this project online accessible?