Pre-Proposal: Add Validation somewhere easily accessible

[Joseph Abrahamson]

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