Pre-Proposal: Add Validation somewhere easily accessible

Mon Sep 22 14:49:25 UTC 2014

I was just thinking about this opportunity last night. I think it is a fairly appropriate place for Validation and lets `errors` include the type naturally. Further, Michael is right in that so long as the package dependency is above `semigroups` then it’d be more accurate to state the instance using Semigroup e. I’d personally be in favor of that as well.

I’d be interested in entertaining a small amount of bikeshedding over the name as well. I wrote this up using Validation to mime the `validation` package, but have personally used a number of names in the past. Other potential options include: Result, Collect, and Combine.

I propose sticking with Validation (and the implementation in the head of this thread, potentially modulo [Monoid\Semigroup]) by default but would like to hear if anyone has strong justification for another name.

Joseph

On Mon, Sep 22, 2014 at 10:41 AM, Michael Snoyman <michael at snoyman.com>
wrote:

> 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/ab498ea7/attachment.html>