2

see the title. For a small tool I am writing I wanted to introduce a simple boolean filter language and decided to do that "properly" and use a parser-generator. After playing around with grako a bit I found I like it and got the filter-language done fairly quick (which is also nice :))

The problem is now, if I want to use the tool on other computers or give it to other people I first have to somehow make grako available there, which is a bit bothersome, because everything else is standard python3 stuff.

I guess it is possible by co-packaging the necessary grako-classes, but that seems a bit messy (licensing would be mentioned in any way). Maybe I have overlooked some built-in method.

mageta
  • 597
  • 2
  • 6
  • 12
  • Sometimes parser generators are overkill. If you want to write just a simple boolean expression language, you can do that pretty effectively with a hand-written recursive descent parser and no outside package dependencies. See http://stackoverflow.com/questions/2245962/is-there-an-alternative-for-flex-bison-that-is-usable-on-8-bit-embedded-systems/2336769#2336769 – Ira Baxter Mar 20 '16 at 10:03
  • Thx for the hint. I agree, using a generator for this was maybe a bit over the top, but its just a "for fun"-thing and I did use one just because I haven't played around with any in quite a while ;-). – mageta Mar 20 '16 at 10:10

1 Answers1

1

The short answer is No.

Grako-generated parsers do require the grako library.

For example:

with self._group():
    with self._choice():
        with self._option():
            self._token('nameguard')
        with self._option():
            self._token('ignorecase')
        with self._option():
            self._token('left_recursion')
        self._error('expecting one of: ignorecase left_recursion nameguard')

All the self._xyz() come from either grako.contexts.ParseContext or grako.parsing.Parser. The backtracking, caching, and the book-keeping required are all hidden behind context managers and decorators.

Having generated parsers depend on grako was a design choice aimed at making the parsers smaller and easier to understand, which was one of the primary objectives of the project (as there are many otherwise-great parser generators that produce obfuscated code).

The other option was to copy the code that the generated parsers could depend on onto each parser, but that seemed a bit unpythonic.

Apalala
  • 8,159
  • 3
  • 26
  • 47
  • 1
    Clarification: It is not necessary to learn the Grako library to build parsers or translators: The README is enough. BUT... to deal with complex source or target languages it is best if utilitors either study what the Grako library provides in that regard, or find other sources for the equivalent or better. – Apalala Mar 30 '16 at 00:00