Re: parsing tools, was Dragon Book - update necessary?

Randall Hyde <rhyde@cs.ucr.edu>
4 Nov 2000 01:42:42 -0500

          From comp.compilers

Related articles
[9 earlier articles]
Re: parsing tools, was Dragon Book - update necessary? jim.granville@designtools.co.nz (Jim Granville) (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? iank@idiom.com (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? jmochel@foliage.com (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? joachim_d@gmx.de (Joachim Durchholz) (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? LLkParsing@aol.com (2000-11-01)
Re: parsing tools, was Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-11-04)
Re: parsing tools, was Dragon Book - update necessary? rhyde@cs.ucr.edu (Randall Hyde) (2000-11-04)
Re: parsing tools, was Dragon Book - update necessary? LLkParsing@aol.com (2000-11-05)
| List of all articles for this month |

From: Randall Hyde <rhyde@cs.ucr.edu>
Newsgroups: comp.compilers
Date: 4 Nov 2000 01:42:42 -0500
Organization: Posted via Supernews, http://www.supernews.com
References: 00-10-061 00-10-067 00-10-093 00-10-109 00-10-130 00-10-193 00-10-209 00-10-221 00-11-014
Keywords: lex, performance
Posted-Date: 04 Nov 2000 01:42:42 EST

LLkParsing@aol.com at LLkParsing@aol.com wrote on 11/1/00 4:51 PM:


> - Scanner generators are more trouble than they are worth.
That was certainly true for HLA with the version of FLEX I was using.
Newer versions of FLEX would have made this much easier, IMO.
OTOH, the scanner was only 5,000 lines of FLEX/C code, a rather
trivial amount compared to the rest of the compiler.


Definitely in v2.0 I will write the scanner in assembly language. I
will also explore the use memory mapped files. Hopefully the
combination of these two will give me at least an order of magnitude
boost in performance (HLA definitely speeds the vast majority of its
time in the scanner.


> - Interpreted languages like Java do not scale unless they can be
> compiled.


Not sure what you mean here. Could you elaborate? Interpreted code
typically runs some constant factor slower than compiled code. An
algorithm should "scale" at the same rate whether it is interpreted or
not.


Of course, no one likes waiting for tools to do their job.
That was my main concern with ANTLR.


> - The main advantage of hand-coded compilers is flexibility. Your
> application seems to need flexibility above all else.


OTOH, if a tool provides all the flexibility you need, it can save a
lot of effort. I'm not sure my application needs flexibility above
all else, but it's certainly clear that FLEX/Bison are not flexible
enough for HLA. What's less clear is whether ANTLR will do the job.
Hand-coding the compiler is less risky insofar as hand-coding is
certainly the most flexible approach and will do the job. The risk is
that a tool like ANTLR will be sufficiently flexible and development
with ANTLR could save considerable effort.


>
> Best of luck with it.
Thanks,
Despite my counterpoints, I do believe I'm mostly in agreement
with your comments.
Randy Hyde


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.