On Sat, 2010-10-16 at 16:44 +0100, Thomas Schilling wrote:

I'm CC'ing Duncan, in case he has a better idea.

On 13 October 2010 19:44, Niklas Broberg wrote:

...

...

What I want specifically is to have happy produce a GLR parser from my .ly file, and I want this to happen during 'cabal install'. Which in turn means I want cabal to pass the "--glr" flag to happy during setup. My best guess is that I might want to use 'ppHappy' [1], or something in the vicinity, but there's no documentation for the combinator and it's far from obvious how to pass arguments to it.

I think the "right solution" is for the happy source file to specify what kind of grammar it is / should be produced. Yes, that would mean modifying happy. Duncan

On Wed, 2010-10-20 at 10:37 +0200, Niklas Broberg wrote:

...

I think the "right solution" is for the happy source file to specify what kind of grammar it is / should be produced. Yes, that would mean modifying happy.

Hmm, I agree with you in this particular case, regarding the grammar, since it really only makes sense for any given happy grammar to generate either kind of parser. But such a solution still wouldn't answer the general question about passing flags to preprocessors. Certainly not all such use cases are best fixed by pushing the flags into the pre-processed files.

I like to see it as an issue of the design of the whole system, not just adapting cabal to existing half-thought-out tools. With preprocessor flags the first question is who picks the flags. If it is the person doing the build then we handle that already. If it is the package author then it needs more careful analysis. Yes we could go and add a foo-options for every single pre-processor but that's not obviously a good idea. Yes you can have full control by writing code in the Setup.hs (and it could be easier to do that) but again it's not a very nice solution in general. I think we have a habit of just adding flags to such tools and saying "let the build system handle it" without really thinking carefully about where the right place to specify things should be. My view is that for the most part, source modules ought to be self-descriptive so that they can be built with zero configuration. For basic Haskell modules we do this already, we have a standard convention on file extension, file <-> module name mapping, language pragmas, etc etc. This is what allows ghci / ghc --make to work in most cases (and in principle should allow a future cabal to work even without a .cabal file for many simple projects -- like hmake did for years). For preprocessors we have some convention, we mostly use file name extensions. For more detailed variations I think it does make sense to stick it in the source module. The harder cases are things like preprocessors which genuinely have multiple modes. I don't mean things like happy's GLR since as I understand it you really design the grammar specifically for the approach. There are other tools where from the same source you can and do generate multiple outputs. There it is harder to establish a convention that allows for zero-configuration. Similarly, documentation is a mess because there are few established conventions, so much more grungy configuration is needed. Duncan