Pre-Proposal: Add Validation somewhere easily accessible

[Edward Kmett]

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