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

[C. Mundi]

I hope you didn't think I was suggesting that your work (or Johannes' work)
is lagging TParr.  Quite the opposite.  It's amazing how well you guys have
mind-melded.  And I recognize from my own work elsewhere the almost
super-human effort that requires.  "Thank you."  You contributors don't hear
that nearly enough here.

You've just about talked me out of IKVM.  I need to ponder it more.  Thank
you.

And you make an excellent point about the C# target being ahead of Java in
some aspects.

Although I failed to say so, my desire to sync with TParr (or at least have
the option) is stability.  I'm not interested in chasing the latest
pre-release features.  But I am interested in getting the latest fixes.  So
even if the C# target gets "ahead" of the Java reference, I would probably
not use the C# enhancements until they were cross-ported to Java anyway.

Thanks and congratulations to all of you who make this amazing tool work for
so many more of us.

C. Mundi


On Fri, Feb 6, 2009 at 1:50 AM, Sam Harwell <sharwell at pixelminegames.com>wrote:

>  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/898a0a74/attachment.html