I mean getOpt has its own way of keeping track of errors and whatever construction I use to collect typechecking errors will need another. If only there were a way for the typechecking errors messages to be picked up by getOpt itself, and returned with its own native error messages.


On Sat, Jun 28, 2014 at 5:30 PM, John Meacham <john@repetae.net> wrote:
What is the issue with other option errors and type matches being
treated differently? I mean, you can print the same error message. A
handy trick is to define a helper for building your options list that
passes the option names into your monadic option builder function so
it can print the name of the option that was given the wrong type in a
generic and pretty way. I generally use a Writer monad to collect
errors rather than an Error monad that cuts out early so all option
errors can be accumulated and printed together.

    John

On Sat, Jun 28, 2014 at 12:28 PM, Johan Larson <johan.g.larson@gmail.com> wrote:
> I've been looking at choices for parsing command line arguments, including
> getOpt. The examples I can find focus on string arguments, whereas I am
> interested in numbers. In the application at hand, it is particularly
> important to issue clear error messages when arguments don't parse as
> numbers or are out of range.
>
> I could use getOpt as a first pass with string arguments and then turn the
> strings into validated numbers in a second pass, but that's a bit awkward.
> Alternately I could use the options records with Options -> IO Options
> functions. But both of these solutions treat type mismatches differently
> from other options errors.
>
> Has anyone found a cleaner solution?
>
> --
> Johan Larson -- Toronto, Canada
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



--
John Meacham - http://notanumber.net/



--
Johan Larson -- Toronto, Canada