[antlr-interest] Q: opinions on ikvm + antlr3 ?

Johannes Luber JALuber at gmx.de
Fri Feb 6 08:25:10 PST 2009


> I have a further thought on this:
> 
> On Fri, Feb 6, 2009 at 2:03 AM, Johannes Luber <JALuber at gmx.de> wrote:
> 
> Con: I haven't checked it, but I believe that IKVM won't create the
> .NETisms
> > like properties instead getters and setters. If true, your parser
> backend
> > will be schizophrenic regarding the approaches.
> > Con: .NET-only additions like #pragmas to silence warnings won't be
> > inlcuded.
> 
> 
> I think I managed to trick myself, by forgetting that I've been looking at
> too many alternatives.
> 
> What I'm thinking of is using the ANTLR java tool and writing all of my
> actions in Java.  Next, compile the java to bytecode targeting the JVM.
>  Then, use ikvmc to do a one-time translation of the JVM bytecode to .NET
> IL
> bytecode, i.e. a .NET assembly.  According to the IKVM folks, I would have
> to write my own classloder if I need to load Java classes dynamicaly.
> Otherwise, I would never see C#, because I'd be coding in Java.
> 
> (Ok, it's actually a little more complex.  Write lexer in Java.  Compile
> lexer class to JVM bytecode.  Recompile to IL (ikvmc).  Create java stub
> for
> lexer IL (ikvmstub).  Write parser in Java, by getting token stream from
> java stub of lexer.  Compile parser class to JVM bytecode.  Recompile to
> IL.  Done.
> 
> It seems like the properties v. setter/getter concern goes away in this
> scenario.  Am I completely wrong?
> 
> C. Mundi

You still have to interface your parser. Depending on how you do it, you may or may not have the need to access things like "token.getText()" in C#.

Johannes

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01


More information about the antlr-interest mailing list