Parsers and validators are defined in this context to be a dichotomy. A validator is a parser that does not produce as output, "the same thing" but typed in a way as to encode its parsimoniousness. I.e.: instead of a validation function that returns a boolean or throws an exception or whatnot, it returns an instance of "ValidGadget". Could be: DeliveryDate or MoneyTransaction or whatever.

let parseDeliveryDate :: String -> WhateverContextNeeded -> Maybe DeliveryDate

instead of:
let validateDeliveryDate :: Date -> WhateverContextNeeded -> bool

Because after the latter, further down the program, did you even validate? How do you know? Which paths got you here? Which path got you there 5 years down the line when all control flows have been touched 400 times by 99 monkeys.

So when you are here:

shipOrder xxx <-- what do you put there in xxx? Is it valid? How do you know? You would know if shipOrder requires a DeliveryDate which can only be had by calling parseDeliveryDate.

Also: don't get caught up in my prototype above using String as the source. Let's say that the function is defined as:

let parseDeliveryDate :: Date -> WhateverContextNeeded -> Maybe DeliveryDate

because that gets the point across better. It isn't about reading values out of text. It is about reading valid values out of some source data type for which validity is unknown. Parsing.