Tomasz Zielonka wrote:
and handle options as functions from Config to Config:
I find this approach very convenient, but I push it a bit further. Some time ago I wrote a small article about this:
http://www.haskell.org/pipermail/haskell/2004-January/013412.html
[from there]
-- Here we thread startOptions through all supplied option actions opts <- foldl (>>=) (return startOptions) actions
So the order in actions is important and therefore the order of options on the commandline is important. But how to handle dependencies between options using this technique? I can image two solutions: 1: Every dependency 'a implies b' has to be checked in both functions, the one for a and the one for b. 2: An order for the actions has to be specified, maybe by decorating the option list with priorities. But both solutions seems to be tedious and error prone. In contrast the sum-type technique first reads all options and then post-processes the complete set. Here the order of options on the commandline has no impact on the final result. Regards, Mirko Rahn -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---