Idiomatic formatting of error messages and other complex strings

When creating a command-line app, one usually has to do some kind of parsing of command-line arguments, and print an error message if a different number of arguments is expected, or they do not make sense. For the sake of simplicity let's say that a program takes a positive integer as its only argument. Parsing and further program execution in Haskell can be done like this:

main :: IO ()
main = do
  args <- getArgs
  case args of
    [arg] -> case readMaybe arg :: Maybe Int of
      Just n | n > 0 -> runProg n
      Just n         -> die $ "expected a positive integer (got: " <> show n <> ")"
      Nothing        -> die $ "expected an integer (got: " <> arg <> ")"
    _ -> die $ "expected exactly one argument (got: " <> show (length args) <> ")"

Creation of appropriate error message feels clunky to me, especially combined with show anywhere I want to include a non-string argument. There is printf but this on the other hand feels... not Haskell-y. What would be the idiomatic approach here? Perhaps my bias against the methods I listed is unjustified and it is, in fact, idiomatic Haskell?

As per the comment, if you're actually parsing command line arguments, you probably want to use optparse-applicative (or maybe optparse).

More generally, I think a reasonably idiomatic way of constructing complex error messages in Haskell is to represent the errors with an algebraic data type:

data OptError
  = BadArgCount Int Int  -- expected, actual
  | NotInteger String
  | NotPositive Int

supply a pretty-printer:

errorMessage :: OptError -> String
errorMessage (BadArgCount exp act) = "expected " <> show exp 
                                     <> " arguments, got " <> show act
errorMessage (NotInteger str) = "expected integer, got " <> show str
errorMessage (NotPositive n) = "expected positive integer, got " <> show n

and perform the processing in a monad that supports throwing errors:

data Args = Args Int

processArgs :: [String] -> Either OptError Args
processArgs [x] = case readMaybe x of
  Just n | n > 0     -> pure $ Args n
         | otherwise -> throwError $ NotPositive n
  Nothing            -> throwError $ NotInteger x
processArgs xs       =  throwError $ BadArgCount 1 (length xs)

This is certainly overkill for argument processing in a small command-line utility, but it works well in other contexts that demand complex error reporting, and it has several advantages over the die ... approach:

• All the error messages are tabulated in one place, so you know exactly what errors the processArgs function can throw.
• Error construction is type checked, reducing the potential for errors in your error handling code.
• Error reporting is separated from error rendering. This is useful for internationalization, separate error reporting styles for terminal and non-terminal output, reuse of the functions in driver code that wants to handle errors itself, etc. It's also more ergonomic for development, since you don't have to take a break from "real coding" to make up a sensible error message. This typically results in better error reporting in the final product, since it encourages you to write a clear, consistent set of error messages all at once, after the core logic is finished.
• It facilitates refactoring the errors systematically, for example to add location information (not relevant for command line arguments, but relevant for errors in input files, for example), or to add hints/recommendations for correction.
• It's relatively easy to define a custom monad that also supports warnings and "non-fatal" errors that allow further error checking to continue, generating a list of errors all at once, instead of failing after the first error.

I haven't used this approach for command line arguments, since I usually use optparse-applicative. But, I have used it when coding up interpreters.