on second thought, user-defined profiles are a two-edged sword, negating the documentation advantages of in-source flags. better to handle that in the editor/ide. but predefined flag profiles would still seem to make sense? there is something wrong about this wealth of options. it is great that one has all that control over details, but it also makes it more difficult to get things right (eg, i was surprised that -O doesn't unbox strict fields by default). even a formula one driver doesn't control every lever himself, that's up to the team. for optimisations, i used to have a simple picture in mind (from my c days, i guess?), when ghci is no longer fast enough, that is: no -O: standard executables are fast enough, thank you -O: standard executables aren't fast enough, do something about it, but don't bother me with the details -O2: i need your best _safe_ optimisation efforts, and i'm prepared to pay for that with longer compilation times -O3: i need your absolute best optimisation efforts, and i'm prepared to verify myself that optimisations that cannot automatically be checked for safety have no serious negative effect on the results (it would be nice if you told me which potentially unsafe optimisations you used in compilation) on top of that, as an alternative to -O3, specific tradeoffs would be useful, where i specify whether i want to optimize for space or for time, or which kinds of optimization opportunities the compiler should pay attention to, such as strictness, unboxing, floating point ops, etc.. but even here i wouldn't want to give platform-specific options, i'd want the compiler to choose the most appropriate options, given my specified tradeoffs and emphasis, taking into account platform and self-knowledge. so, i'd say -Ofp, and the compiler might pick:
-fvia-C -fexcess-precision -optc-mfpmath=sse2
if i'm on a platform and compiler version where that is an appropriate selection of flags to get the best floating point performance. and it might pick a different selection of flags on a different platform, or with a different compiler version.
perhaps this should be generalised to ghc flag profiles, to cover things like '-fno-monomorphism-restriction -fno-mono-pat-binds' or '-fglasgow-exts -fallow-undecidable-instances; and the like?
that is a slightly different story, and it might be useful (a) to provide flag groups (-fno-mono*) and (b) to specify implication (just about every language extension flag implies -fglasgow-exts, so there's no need to specify that again, and there might be other opportunities for reducing groups of options with a single maximum in the implication order; one might even introduce pseudo-flags for grouping, such as -fhaskell2;-). claus