Pre-Proposal: Add Validation somewhere easily accessible

[Michael Snoyman]

FWIW, my neither package[1] (deprecated in favor of your either package)
does in fact define this Applicative Either datatype (though under a
different name). IMO, either is the right place for this.

One minor bikeshedding question: it seems like the Applicative instance
doesn't require a Monoid constraint, but rather only a Semigroup
constraint. Since semigroup is already a dependency of either, would it
make sense to define the instance as such?

[1]
http://hackage.haskell.org/package/neither-0.3.1.1/docs/Data-Neither.html

On Mon, Sep 22, 2014 at 5:38 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Another option is to consider sliding it up into the 'either' package
> which is a dependency of errors. I'd be willing to help out there.
>
> -Edward
>
> On Sun, Sep 21, 2014 at 4:56 PM, Joseph Abrahamson <me at jspha.com> wrote:
>
>> I think errors is a good place to begin a process like what Ed suggests.
>> I do think that, ultimately, it’s a more pervasively useful type than
>> that—just to leave that on the record.
>>
>> Joseph
>>
>>
>> On Sun, Sep 21, 2014 at 2:05 PM, Greg Weber <greg at gregweber.info> wrote:
>>
>>> The errors package seems like a good location for it.
>>>
>>> On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson <me at jspha.com>
>>> wrote:
>>>
>>>> I think that's my feeling about the risk of placing it in such a
>>>> prominent place as transformers as well. I feel that such a core location
>>>> is not necessarily needed, but the functionality provided would not be
>>>> difficult to standardize relatively quickly.
>>>>
>>>> The benefit is to make the technique more widely known and more easily
>>>> included. Typically its use tosh involves the addition of either an extra
>>>> one-off package which provides little extra and more deps (this is the case
>>>> today with `validation` especially given the lens/profunctors dep but even
>>>> without) or nestled deep inside another package with a different focus.
>>>>
>>>> So I feel the proper place for such a simple type is somewhere inside a
>>>> toolkit of other commonly used types of its brand. If there were a good
>>>> `applicatives` package that would be ideal. I mentioned transformers as
>>>> nothing more or less than the nearest approximation to that which I know of.
>>>>
>>>> Joseph
>>>>
>>>>
>>>> On Sun, Sep 21, 2014 at 1:17 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>>>
>>>>> I suppose ultimately the question I'd have is what is gained from
>>>>> standardization here per se?
>>>>>
>>>>> I can see the merit of the authors of those libraries coming together
>>>>> to agree on a common API and type if they can, but I think I'd rather see
>>>>> that sort of consolidation out in package space than in a package that
>>>>> falls under the purview of the libraries@ process -- and if they
>>>>> can't come together that too says something.
>>>>>
>>>>> Tying it to transformers in particular would tie changes to a couple
>>>>> year long dev cycle. It is a ghc build package, and hence not easily
>>>>> upgraded for users. That point in the design space strikes me as even worse
>>>>> than the status quo.
>>>>>
>>>>> Once such a package exists and it sees wide adoption, then the
>>>>> discussion of whether it belongs in the platform seems to make sense.
>>>>>
>>>>> -Edward
>>>>>
>>>>> > On Sep 21, 2014, at 1:05 PM, "Joseph Abrahamson" <me at jspha.com>
>>>>> wrote:
>>>>> >
>>>>> > The “purely applicative Either” is Either with a new Applicative
>>>>> interface which can no longer take a corresponding Monad interface. I have
>>>>> personally reinvented it over and over although it is perhaps commonly
>>>>> known as Validation:
>>>>> >
>>>>> > data Validation e a = Invalid e | Valid a deriving ( Show, Functor,
>>>>> … )
>>>>> >
>>>>> > instance Monoid e => Applicative (Validation e) where
>>>>> > pure = Valid
>>>>> > Invalid e1 <*> Invalid e2 = Invalid (e1 <> e2)
>>>>> > Invalid e1 <*> _ = Invalid e1
>>>>> > <*> Invalid e2 = Invalid e2
>>>>> > Valid f <*> Valid a = Valid (f a)
>>>>> >
>>>>> > -- No corresponding Monad
>>>>> >
>>>>> > It could be perhaps better implemented as a newtype wrapper over
>>>>> Either to facilitate rapid conversion to the more common type.
>>>>> >
>>>>> > Validation appears in its own package developed by Tony Morris and
>>>>> Nick Partridge. It also exists in Jonathan Sterling’s Vinyl package under
>>>>> the name Data.Vinyl.Idiom.Validation.Result. Gabriel Gonzalez has also told
>>>>> me that he’d be happy to add it to his `errors` package if a PR was made.
>>>>> >
>>>>> > The common use for Validation is to traverse over a structure and
>>>>> accumulate errors throughout it. In other words, failures should not halt
>>>>> the process and we can think of each operation as occurring in parallel.
>>>>> >
>>>>> > Not only is Validation a good example of an “Applicative without a
>>>>> Monad” its also a very useful practical type.
>>>>> >
>>>>> > I would like to build a proposal to include Validation in some form
>>>>> in a common package. Despite the misalignment with the name, `transformers`
>>>>> seems like a plausible target, though I fear changes to that package are
>>>>> rarely worth the pain. Suggestions on implementation and target package are
>>>>> welcome. Pending informative feedback, I will try to write a true proposal
>>>>> within 2 weeks.
>>>>> >
>>>>> > Thanks everyone,
>>>>> >
>>>>> > Joseph
>>>>> >
>>>>> > Joseph
>>>>> > _______________________________________________
>>>>> > Libraries mailing list
>>>>> > Libraries at haskell.org
>>>>> > http://www.haskell.org/mailman/listinfo/libraries
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140922/52a1b4a0/attachment-0001.html>