[antlr-interest] Re: build issues: bytecode assembly generation

micheal_jor open.zone at virgin.net
Sat Oct 23 02:24:40 PDT 2004



--- In antlr-interest at yahoogroups.com, "Don Caton" <dcaton at s...> wrote:
> Michael:
> 
> Yes, support for using ANTLR with MSVC.  But I hope I don't sound
like I'm
> whining.

Not at all. Highlighting the issue on the list increases the
likelihood of a solution.

> Java isn't present on
> many, if not most Windows installations and it isn't something that most
> Windows folks are familiar with.  And even if you find your way to
java.com
> and figure out what to d/l, who really wants to d/l a huge runtime
> environment just to run a single tool?  The average Windows programmer
> probably never heard of Cygwin or other emulators either.  The
barrier to
> entry is high enough on Windows that it may discourage people from using
> Antlr, and that would be a real shame.

These are some good points that the ANTLR community has already
started addressing. The file sharing section of the website contains
the following binary downloads for ANTLR:

1. GCJ/Cygwin - stand alone executable that requires Cygwin.
2. GCJ/MingW - stand alone executable with no dependency on Cygwin.
3. J#.NET - stand alone executable that requires the .NET framework
and the J# runtime libraries (this is for 2.7.2 but the related
project files package may be a basis for getting a J# exe for 2.7.4)

> Perhaps when I have time to come up for air, I'll package the antlr
stuff up
> in a Windows installer and submit it to the antlr site, along with MSVC
> project files and such.

I'm sure that would be appreciated.

> Far as the studies you cite go, all they prove is that Java appears
to be
> the proper tool for those particular projects, and I don't doubt that at
> all.

Perhaps. They also show an increase in productivity even when the
developers were C++ veterans just learning Java.

> There's no question Java offers many benefits and it is a good choice
> for many types of programming.  I just don't think parsing is something
> you'd want to do in a language with the runtime overhead of Java.  I
> probably wouldn't write a parser in a .NET language for the same reason.
> Maybe a prototype, but not production code.

The issue isn't so much the runtime overhead or increased memory
consumption IMO. It's much more a lack of native support for what Tim
Bray termed "Heavy Text Processing" -
http://www.tbray.org/ongoing/When/200x/2003/04/30/JavaStrings

I'd venture that this is only an issue for a [very] small percentage
of systems that perform parsing and your project sounds like one of them.

With regards to the .NET platform (C# esp.), pointers make all the
difference. Assuming you can use them, none of this applies.

> Which brings me back to my original question of "why Java?" for this
type of
> thing?  I suppose for light duty parsing requirements it might be
ok, but

Precisely. The ANTLR tool itself is a "light duty parsing tool" and
would be just as useful if it had been written in VBScript or Awk.
Java's productivity benefits and painless cross-OS portability were
more important than C/C++'s support for low-level bit-twiddling.

> I can't imagine that an Antlr-generated Java lexer/parser could ever
approach
> the speed of a fully optimized C++ one.

Not without "tweakable" pointer types (unsafe/native C# for example
would scream). But it can do much better than most parsing systems
actually *need*.

> I'm rarely in favor of sacrificing
> runtime efficiency for programmer convenience.

Productivity, not convenience. It is often more important to be able
to quickly produce 5 adequately efficient systems in a given time
frame than just one insanely fast system.

Micheal






 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the antlr-interest mailing list