Skip to content


Subversion checkout URL

You can clone with
Download ZIP


GLR feature needs to be usable without command line args #3

dcoutts opened this Issue · 1 comment

2 participants


The GLR feature in Happy is currently not usable for people using cabal (ie everyone) because the GLR feature requires the use of command line arguments, and Cabal provides no way to set happy command line arguments in the .cabal file.

Now you may say "well then, cabal should just let me specify command line arguments to happy". But actually this behaviour in Cabal is by design. The right place to say if your parser is GLR or not is in the .y file itself, not in the .cabal file. In practice each .y file is either going to be GLR or not, and this is something that is decided by the author, not the person building the package.

Exactly how you do this is up to you of course, but happy already has a syntax for directives, like %name, so you could just add something like

%grammar glr

and similarly for the functionality of the --decode and --filter options.

The general principle here, is to consider that there is a division of roles between the author of the program/package and the person building the package. The person building can decide things like optimisation levels, where input and output files live etc. The author decides the code and anything that is necessary for the meaning of that code. The preferable place to put the code (and related) is in the file itself, or sometimes in the .cabal file, but the less configuration the better. The preferable place for the builder to specify things is in the build environment (cabal command line, cabal config file, sandbox config file etc).


I've started implementing support for this in happy.

I'm using a %flags directive at the moment (but I'm open to suggestions). The idea is that the user can specify any command line options they want right in the grammar file.

Here is an example:

%flags { --glr --filter --decode -m foo }

It would be very easy to make the directive more specific, and use something like %grammar glr, or %backend glr. I just thought that making the mechanism take any command line flags would provide more utility with less work.

My work on this is here:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.