Pre-Proposal: Add Validation somewhere easily accessible

[Greg Weber]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140921/b629b81a/attachment.html>