Pre-Proposal: Add Validation somewhere easily accessible

[Joseph Abrahamson]

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