On 07/20/2013 04:49 PM, adam vogt wrote:
Hi Michael,
It's fairly straightforward to generate the new data with template
haskell [1], and on the same page, section 10.7 'generic' zipWith is
likely to be similar to your merging code.
[1]
On Sat, Jul 20, 2013 at 12:14 AM, Michael Orlitzky mich...@orlitzky.com wrote:
For posterity, I report failure =)
Hi Michael,
It's fairly straightforward to generate the new data with template
haskell [1], and on the same page, section 10.7 'generic' zipWith is
likely to be similar to your
On 07/16/2013 04:57 PM, Michael Orlitzky wrote:
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
default = Cfg False
The user can override the defaults one of
On Tue, Jul 16, 2013 at 04:57:59PM -0400, Michael Orlitzky wrote:
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields
On 07/16/2013 09:57 PM, Michael Orlitzky wrote:
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
On 07/16/2013 05:06 PM, Tom Ellis wrote:
On Tue, Jul 16, 2013 at 04:57:59PM -0400, Michael Orlitzky wrote:
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a
The suggestion of parameterizing on a functor would be good, however
there's another approach I've often seen (although it's not quite what
you've asked for). You can leave your config datatype alone, but instead
of making it a monoid have your configuration parsers return functions with
the type
Oh, very nice. It seems reasonable to extend this to Cfg - IO Cfg to
support things like dynamically loading config files, if needed.
On Jul 16, 2013 5:42 PM, John Lato jwl...@gmail.com wrote:
The suggestion of parameterizing on a functor would be good, however
there's another approach I've
On 07/16/2013 08:41 PM, John Lato wrote:
The suggestion of parameterizing on a functor would be good, however
there's another approach I've often seen (although it's not quite what
you've asked for). You can leave your config datatype alone, but
instead of making it a monoid have your
10 matches
Mail list logo
