Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java Parser-Generator for these requirements

My script language ports methods from the java.awt.Graphics class into commands (like setcolor_0,127,214,255 //R,G,B,Alpha or fillrect_50,25,100,75 //x,y,w,h) into a picture so I avoid having to write an entire program every time.

The language is limited to pseudo functions and commands mapped to Graphics method calls, plus output specifiers as a header to each script, but I want to add more. The script serves as parser and interpreter, but processing input strings directly is inadequate. Found parser and lexer generators keep running into the same two problems:

  • The generated parser will require some form of runtime dependency(/-ies) which only the generator can provide (e.g.: Beaver's products needing its own runtime files), or
  • The generator does not appear to have been fully developed, if not then the generator still makes at least one disagreeable assumption. (e.g.: Jay's method of generating source code without enclosing class markings and assumption that all classes will be in the same file).

I would like to steer clear of ANTLR. I need a parser-generator which:

  • Has plenty of documentation (external or otherwise) at no cost.
  • Builds a parser that:
    • Does not require external dependencies.
    • Outputs Java source code which is 1.5 or later and easy to read.
    • Generates a properly encapsulated class.
like image 600
Chuck Rittenhouse Avatar asked Apr 17 '26 13:04

Chuck Rittenhouse


1 Answers

Welcome to the vast world of Software Reuse, where you can choose among a vast array of components, all of which don't do quite what you want.

It is probably unrealistic to get a parser generator package that doesn't have "external dependencies". Almost any complex piece of software uses a library of special functions to support its purposes, and parser generators aren't really different. The distinction you make seems rather artificial, too. Imagine that a parser generator simply emitted the code for the external library, rather than simply referenced it. The amount of code you got, and how it was organized, would not be different. Why then would you object to the library version?

If you want parser generators that are not incomplete, I suggest you stick with mature ones. ANTLR and JavaCC in the Java world have quite long and successful track records.

If you insist you still don't want such things, you can always hand-code a recursive descent parser. This is especially effective for "simple" languages, such as yours appears to be. [What you'll discover is that you end up coding your own support library, although it doesn't have to be very big.]

like image 102
Ira Baxter Avatar answered Apr 20 '26 02:04

Ira Baxter



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!