Haskell：编码通用模式

Question

To begin with, some motivation: I want to take configuration from multiple places - command line arguments, possibly config files, some other service. I don't have any particular care for the format of these sources. What I would like to do is describe a schema for that configuration and have pluggable sources generate parsers/writers for that config as necessary. The schema should also encode things such as help text, possibly completion options, etc.

Here's the basis of what I have so far:

data Name =
    LongName String
  | ShortName Char

data OptionDefault a = OptionDefault (Maybe a) (Maybe (a -> String))

data OptionDescr = OptionDescr {
    odNames :: [Name]
  , odSummary :: String
  , odDetail :: String
}

data Option a = Option {
    oReader :: Monad m => String -> m a
  , oDefault :: OptionDefault a
  , oDescr :: OptionDescr
}

The thing I'm not sure how to do is compose these - eg to define a config section as being, say, three options of types Option Foo , Option Bar and Option Baz as well as a function f :: Foo -> Bar -> Baz -> FBBSection . This is a different question to composing the Parsers , which should be done at a later date by a generator for the specific format.

The only thing I can think of is to store the options as some kind of HList, and force some kind of fold composition for f - any other ideas?

Answer 1

If you have an Applicative instance for Option:

foo :: Option Foo
bar :: Option Bar
baz :: Option Baz
f :: Foo -> Bar -> Baz -> FBBSection

fbbSection :: Option FBBSection
fbbSection = f <$> foo <*> bar <*> baz

Now, the trouble is in writing the Applicative instance. First of all, you need a Functor instance, but you can't really provide one: OptionDefault is an invariant functor because its type parameter a occurs in both a positive position Maybe a and in a negative position Maybe (a -> String) . The Functor typeclass in Haskell is only for covariant functors.

You might re-examine your data to see if you can make it covariant. There might be an equivalent for Applicative that is invariant though I'm not sure; I'm not sure how currying works for isomorphisms, if it does at all, and Applicative is actually rather dependent on currying, from a categorical perspective.

After you got though all of that, you'd need to define how your Applicative combined OptionDescr values.