I worked out some more complete examples of validations using the Semigroup and Semiring instances today. They're pretty opinionated, but I think having a more completely worked out example in the repository could help newcomers.

Right now they're in a separate repo here, but if this seems like something the maintainers would like, I can clean them up and put them into a proper PR.

Is there a reason for having unV instead of a validation eliminator, like maybe or either? If not, should we deprecate unV in favor of such eliminator?

If I try and create a Validator with the new type it doesn't recognize V as a data constructor.

--my module
import Data.Validation.Semigroup (V(..), V, invalid)

--Try to use it
valid :: forall err result. result -> V err result
valid = V <<< Right

Error: Unknown data constructor V

I'm new to PS, but this article seems to say that V needs to be exported from the Validation lib like V(..) to be able to use it.
https://stackoverflow.com/questions/47677049/importing-newtypes-from-another-module

Am I missing something?

Add valid, akin to invalid. This, because pure requires a Semigroup instance on the error type.

This would make converting to/from Either easier, and newtype deriving can be used for some of the instances (Eq, Ord, Functor, Bifunctor).

Hi folks, would you consider a PR for this?

@garyb Any idea why the release versions are still 0.0.* in this repo? Can I make the next release 0.1.0?

Now that we expose the V constructor and provide a Newtype instance, I don't think it makes a lot of sense to provide toEither too.

For some code to be part of the core libraries, I think there should be quite a high bar to meet. The core team should be able to understand and maintain it, it should be robust and correct, and it should be something we expect people to want to use regularly in their programs. I'm not sure Data.Validation.Semiring meets that bar. I certainly don't understand it - I don't understand why you would want to be able to combine errors in two different ways like that. It has also proven resistant to efforts to document it. Additionally, the type which you're meant to use for accumulating errors, Data.Semiring.Free, isn't even a real Semiring: purescript/purescript-semirings#11.

Given all of these things, I think Data.Validation.Semiring (and probably Data.Semiring.Free too) would be best moved to a separate non-core library.

The Data.Validation.Semigroup V does not have a Bind instance because it can lead to unexpected results despite it otherwise working fine. That makes sense, but when I do want that behavior, I can use andThen. Unfortunately, it means I can't use do notation anymore.

As a workaround, perhaps a module should be added to this repo which exposes the following module?

module Data.Validation.Semigroup.QualifiedDo

import Data.Validation.Semigroup (V, andThen)

bind :: -- type signature
bind = andThen

Then, when imported as import Data.Validation.Semigroup.QualifiedDo as V, we can use V.do. Since its qualified do notation, one is able to see that something 'special' is going on with the bind calls.