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

[Sam Harwell]

I'm behind on my obligations right now (i.e. the StringTemplate request
from earlier this week), but I'll let you know where I'm at and how I'm
planning to solve things.

 

Here at our office we use Perforce internally, but we're not in a
position to expose the ANTLR ports directly. I'm planning on either
setting up a SVN server or requesting a branch in the P4 repo at
antlr.org to mirror my work on the C# ports so people have access to
both the code and binaries. I use ANTLR extensively in some commercial
C# products, so keeping up to date isn't really the problem. Actually,
there are a significant number of changes in the C# port that haven't
made it back to the Java version yet, such as the use of v3 grammars.

 

I've been hesitant to just package up the current source because I'll be
making a number of breaking changes as I continue working. Two examples
are the continued move from get/set functions to properties, and making
function names start with a capital letter. I'll try and get a new set
of binaries and an updated version of nFringe's ANTLR language module
posted next week. I've made a few tweaks to the Visual Studio support
since the last post.

 

Thanks,

Sam Harwell

Pixel Mine, Inc.

 

From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of C. Mundi
Sent: Friday, February 06, 2009 1:50 AM
To: antlr-interest at antlr.org
Subject: [antlr-interest] Q: opinions on ikvm + antlr3 ?

 


I've been asking myself what I would do if I needed to target parsers
for .NET and needed to stay current with the latest from TParr.  This is
not a troll.  It's a serious issue for me.  I've Googled a fair bit of
misinformation.  So I've concluded that I should just ask the people who
know best, who logically are among you who frequent this list.  And I
seem to recall seeing some discussion of this months ago, before I
appreciated its significance.

I'm very impressed with the C# target and the recent work to port the
antlr tool to Visual Studio.  It's really amazing.  It also seems like
an enormous effort for these projects to keep up with TParr's prodigious
pace.  So I was wondering what my experience might be like if I stuck to
the "reference" Java target and used IKVM.NET to re-target my parser's
Java bytecode to the CLI.  I have every intention of trying this out,
but first I thought of some obvious pros and cons:

Pro: meets requirement of staying up-to-the-minute with TParr
Pro: meets requirement of targeting .net
Pro: allows access to arbitrary .net via java stubs created from
assemblies, pretty cool but not required
Pro: gives me an excuse to use java for real after all these years  :)

Con: adds another step to the build-chain, i.e. dependence on the
stability of javac; maybe academic, but listed for completeness
Con: at the mercy of the quality of ikvmc -- debugging is ugly if tests
pass in java but fail in .net
Con: possibly slow runtime performance -- I have to believe that the C#
target is able to do more optimization than the two-step Java -->
Bytecode --> CIL process
Con: hours lost cursing classpath  :)

Some of the con's might be mitigated by runtime profiling in combination
with decompiling the CIL, but any hand-tuning on the .NET side would be
hard to maintain unless accepted by the upstream ikvm developers, which
might not be practical anyway.

These observations may be naive.  I'm interested in what the experts
here have to say about what I should be prepared to face if I go this
route.

This is in no way a comment on the incredible work discussed regularly
on this list.  My requirements might push me in a slightly different
direction, is all.

And I have to believe that some of you have tried ikvm or are using it
and already know a lot that I need to learn.

Thanks,
C. Mundi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090206/a0293c49/attachment.html