Cabal spelunking considered tricky
As I've been maintaining cabal-rpm to try to keep up with developments
in Cabal, I've found myself wondering why it's not using many of the
usual tricks to hide the plumbing, such as a custom monad transformer stack.
Some parameters, such as flags, compiler info, and package descriptions,
pop up simply all over the place, and they're passed around explicitly.
This seems a smidge peculiar. A couple of days with a crowbar and
ReaderT StateT IO would do wonders for readability, if anyone feels so
inclined :-)
On Sun, 2008-04-20 at 13:59 -0700, Bryan O'Sullivan wrote:
As I've been maintaining cabal-rpm to try to keep up with developments in Cabal, I've found myself wondering why it's not using many of the usual tricks to hide the plumbing, such as a custom monad transformer stack.
Some parameters, such as flags, compiler info, and package descriptions, pop up simply all over the place, and they're passed around explicitly. This seems a smidge peculiar. A couple of days with a crowbar and ReaderT StateT IO would do wonders for readability, if anyone feels so inclined :-)
Yeah, it's part of the plan for the new development series. The reason we could not do it in the last is api compatibility with existing Setup.hs scripts. The UserHooks types severely restrict that kind of refactoring but I hope we can redesign UserHooks this dev series. It'll break all custom Setup.hs scripts again though. Duncan
On Sun, 2008-04-20 at 13:59 -0700, Bryan O'Sullivan wrote:
As I've been maintaining cabal-rpm to try to keep up with developments in Cabal, I've found myself wondering why it's not using many of the usual tricks to hide the plumbing, such as a custom monad transformer stack.
One such change I'd like to make is to lift Cabal off the IO monad. There will always have to be IO somewhere down at the bottom but it'll help lots of things to have a layer in between. In particular it'll help us to regularise quite a lot of code. If you're in IO you can do anything and so we often do. A more restricted action monad would help us to better separate deciding what to do from actually doing it. It'd also reduce the number of ways of doing the same thing. I'd also like to separate IO actions that have mutative side effects from IO actions that merely query the system environment. Another useful thing would be to introspect IO actions to dynamically enforce policies, like never writing files outside of ./dist/. Such policies don't have to be global: actionWatcher checkFileWrites $ do ... Another candidate to monadify is logging. At the moment we have to remember to do logging consistently and we do it immediately to stderr. Callers like IDEs would like to get logging output in a more convenient format. Duncan
participants (2)
-
Bryan O'Sullivan -
Duncan Coutts