If we can step back for a moment, I think you're saying that supporting Marcus isn't that important, or that it's too hard. Maybe we could break up the argument along the lines of:
1) Why we should / shouldn't support Marcus
Perhaps a semi-concrete example of a Marcus would help here. Suppose I find a really cool library written in C. It's fast, well documented, somewhat portable and too big to rewrite in Haskell so I write: - a Haskell binding for it - some little auxillary C functions (you often need these when you write bindings for big libraries). If it was available as a Debian (say) package, I might be able to survive in "Angela mode". That is, I'd use the simple installation scripts demonstrated in the Cabal documents. [There are some issues here like arranging for compilation of the auxillary C functions and passing appropriate linker flags to the compiler which may mean that I can't quite use the simple scripts.] But, if the C library comes with a complex configure/makefile system and isn't available as a Debian/FreeBSD/Microsoft/etc package and maybe needs modified a bit for use from Haskell, then installing the Haskell binding requires me to configure, compile and link the C library first. My options for doing this are: - Persuade the cabal authors to add enough config/make functionality to Cabal that I can rewrite the configure/make scripts in some Cabalish syntax. Obviously, this is insane. Too hard to add all that stuff to Cabal and now we have to keep our copy in sync with future releases of the original library. - Invoke the existing config/make infrastructure when installing the Haskell binding. I hope it's obvious that this is the better option. There's probably other examples involving use of complex Haskell preprocessors, machine generated Haskell code, C-to-Haskell translators, etc. which are beyond the simple installation system. -- Alastair Reid