Re: [Haskell-cafe] CmdArgs non-flag arguments with newtypes

On 7/23/13 9:01 PM, Michael Orlitzky wrote:
Obviously not what I want! Has anyone else run into this? Figured out a workaround?
I haven't run into this specific problem, but I do have a sort of workaround. Whenever dealing with CmdArgs (or any similar system) I typically define *two* record types. The first one just gets the raw input from CmdArgs; no more, no less. Thus, for your issue, this record would use String. For other issues mentioned recently about optionality, this record would use Maybe. The second one is the one actually used by the program as the configuration object. This one is generated from the first by performing various sanity checks, filling in defaults, converting types from their CmdArgs version to the version I actually want, etc. IME, regardless of language, trying to conflate these notions of an external-facing parser-state and an internal-facing configuration-record just causes problems and accidental complexity. It's best to keep them separate IMO. -- Live well, ~wren

On 07/23/2013 11:48 PM, wren ng thornton wrote:
On 7/23/13 9:01 PM, Michael Orlitzky wrote:
Obviously not what I want! Has anyone else run into this? Figured out a workaround?
I haven't run into this specific problem, but I do have a sort of workaround. Whenever dealing with CmdArgs (or any similar system) I typically define *two* record types.
The first one just gets the raw input from CmdArgs; no more, no less. Thus, for your issue, this record would use String. For other issues mentioned recently about optionality, this record would use Maybe.
The second one is the one actually used by the program as the configuration object. This one is generated from the first by performing various sanity checks, filling in defaults, converting types from their CmdArgs version to the version I actually want, etc.
IME, regardless of language, trying to conflate these notions of an external-facing parser-state and an internal-facing configuration-record just causes problems and accidental complexity. It's best to keep them separate IMO.
It's not the internal configuration and command-line arguments that I wanted to share, but rather the config /file/ and command-line arguments. Those two are then mashed together into the real configuration data structure at run time. The reason for the newtype is for the config file parsing -- without the newtype, I'm forced to create orphan instances like some kind of animal =) In any case, this turned out to be a real bug and not the usual user error. Neil was nice enough to fix it, and it looks like it already hit hackage, so I'm gonna go give it a shot!
participants (2)
-
Michael Orlitzky
-
wren ng thornton