Add subparser

[mightybyte]

No description provided.

[lpsmith]

Well, you can implement this without resorting to anything in the Internal modules:

subparser :: Text -> ConfigParserM a -> ConfigParserM [(Name, a)]
subparser k p = do 
      groupnames <- subgroups k
      mapM (\gn -> (gn,) <$> localConfig (subgroup gn) p) groupnames

Which is basically included as an example in the README, though there's a couple other things going on (e.g. it also implements a defaulting mechanism, and uses mapA instead of mapM)

[mightybyte]

Ahh yeah. I wrote this before I saw that example in the README. Anyway, I think it would be nice to have something like this included in the API in some form.

[lpsmith]

Maybe. One of the issues though is how to deal with e.g. defaulting. I mean, there doesn't seem to be a good way to implement the README example using subparser. We could bake in a defaulting mechanism, which might be convenient, but also doesn't seem overly principled. I mean, if one wanted a different (more complicated?) defaulting scheme, or didn't want any defaulting scheme at all, one would be left starting over. (But my current feeling is, these sorts of doodads should be simple enough that's not that big of a deal.)

[mightybyte]

The defaulting seems like more of a special case situation to me. subparser seems like a much more general pattern. Yes, it's a relatively simple combination of subgroups, mapM, localConfig, and subgroup. But then again, mapM itself is an even simpler combination of sequenceA and fmap. As a newcomer to this library, I don't know the names of your functions and I'd have to hunt around for all of them. I guarantee you that substantial users of this library will write their own version of subparser over and over again. Why not save them the time?

[lpsmith]

What about something like mapSubgroups :: ConfigParser m => Name -> (Name -> m a) -> m [a]?

That name seems better to me, and the type seems a bit more general.

[mightybyte]

Ooh, that sounds great!