Bikeshedding (new-)repl's commandline UI

Merijn Verstraaten merijn at
Tue May 8 11:02:56 UTC 2018

Ok, so this email concerns two main thing I wanted to run by people before I invest the effort. So in my "avoid recompilation sage" [1] I've run into an issue where reducing local recompilation ends up throwing away flags intended for ghci when running "cabal new-repl". Stemming from a mix of throwing away flags that don't affect build output and the fact that the only way to pass options to ghci at the moment is via "--ghc-option". (See the last 2 comments in the PR for details).

So the solution proposed in the PR was to add a separate "--ghci-option", which leads two issues:

1) All current new-X command have a "CommandUI" that basically mimics the original "install" command in what it returns (i.e. "CommandUI (ConfigFlags, ConfigExFlags, InstallFlags, HaddockFlags)"). Is there a specific reason they're all the same, or is it just a matter of "we haven't had a need to expand any of them yet?". In other words, can I simply extend "replCommand" to take extra flags returned in their own data structure?

2) Secondly, in the PR I proposed "--ghci-option", but that'd honestly result in rather tricky overlap with configured programs, possible undoing part of the work to avoid building configurations, etc. It's also highly GHC specific. I was wondering whether it wouldn't be better to simply add a "--repl-option" instead which just forwards it's arguments to whatever REPL command that happens to get invoked. The added bonus of this approach is that it'd be fairly trivial to apply the same approach to old "repl" so that it works with Setup.hs too (if that's desired).


[1] -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <>

More information about the cabal-devel mailing list