Ross, Duncan, Ian and Simon M met in the morning before the Haskell "fun in afternoon" event in Oxford to thrash out a revised design for Cabal configurations. We think it was quite productive. Here we will try to summarise the state of the proposal at the end of the discussion. We've filled in some details that weren't (well) discussed, so Ross and Simon might not be in total agreement with all of the below. Let's start with some BNF. It's a bit vague (e.g. the string and cabal_stanza productions are not defined, and we haven't said anything about disallowing certain kinds of stanzas inside conditional blocks), but hopefully it gives the right idea. cabal_file: flag_introductions "\n" body flag_introductions: flag_introduction "\n" flag_introductions | <nothing> flag_introduction: "flag:" flagname [ "\n" "description:" string ] body: cabal_stanza "\n" body | "if" conditional "{" body "}" [ "else" "{" body "}" ] body | <nothing> conditional: "os(" string ")" | "arch(" string ")" | "flag(" flagname ")" | "True" | "False" | "!" conditional | conditional "||" conditional | conditional "&&" conditional | "(" conditional ")" Now an example: flag: fps_in_base description: Use a base library that contains fps flag: debug description: Show debugging information if flag(fps_in_base) { build-depends: base >= 2 } else { build-depends: base < 2, fps >= 0.8 } if flag(debug) && os(windows) { cpp-options: -DDEBUG_WINDOWS_STUFF } First we declare two flags, fps_in_base and debug. We've also put in descriptions that might be shown by some Cabal GUI frontend. Now we look at the body. Any os(foo) and arch(foo) conditionals are immediately reduced to either True or False. True, False, if/else, !, ||, && and (...) do what you'd expect. flag(foo) where foo is not introduced is an error. Flags use a three valued logic: They can have the value True, False or Unknown. If the value True or False is given by the user for a particular flag then that flag behaves as that value. The interesting case is when flags have the (default) value Unknown. We start off by assuming all Unknown flags have the value True (the reason for starting with True is that we expect people to normally want to write flags in the sense new_thing_is_available, and we generally want to use new things when possible; there is scope to include a "default: False" in the flag introduction stanza to give the user control over this) and see if we can satisfy the build-deps. If we can, then we are done! Otherwise, we try with the last introduced flag being False, and so on, i.e. we do something like head $ do fps_in_base <- [True, False] debug <- [True, False] guard (satisfies_deps fps_in_base debug) return (body fps_in_base debug) Note that the order is determined by the order in which flags are introduced. Intuitively, it is equivalent to trying the rest of the file with first "True" then "False" for each flag introduced. There is scope for optimisation of this process, but it nevertheless remains exponential in the worst case, with 2^n possibilities (given n flags) needing to be tried. Things are even worse if using cabal-get, which then needs to go off and try to install other packages (making sure to not allow the package we are currently working on to be depended upon by them!) in order to satisfy build-deps. However, we believe that in practice this should not be a problem. We don't think that the blocks-of-stanzas format fits well with configurations, so we have used a style with braces. This also allows us to nest conditionals, which should eliminate some duplication. We also think that the cabal syntax may be made clearer to the user if this style was employed for the basic cabal syntax itself, e.g. library { cabal stanzas } executable { cabal stanzas } executable { cabal stanzas } rather than the current cabal stanzas cabal stanzas cabal stanzas but that is a proposal for another day! Ian and Duncan