Pre-Proposal: Add Validation somewhere easily accessible
Andreas Abel
abela at chalmers.se
Mon Sep 22 15:43:05 UTC 2014
Joseph,
your idiom seems indeed fundamental to some extend and seems to be
rediscovered time and again. (My PhD student showed a version of it to
me very recently.)
I also found that it generalizes the existing "Failing a" in
Control.Applicative.Error
http://hackage.haskell.org/package/applicative-extras-0.1.3/docs/Control-Applicative-Error.html
Control.Applicative.Error is the place where it should go, whether you
generalize the existing package or roll your own...
Bikeshedding: "Failing" sounds more fundamental and generic than
"Validation", so I'd prefer the former. However, "Failing" is too
negative, as if the computation must fail, "CanFail" is less definite.
UPDATE: I found that "Errors e" on
https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applicative-Lift.html
seems to be doing the job of "Validation" already (no nice names of the
operations, though).
Cheers,
Andreas
On 22.09.2014 17:11, Chris Allen wrote:
> I was already working on adding it to errors because of EitherT - should
> it go into either instead?
>
> Sent from my iPhone
>
> On Sep 22, 2014, at 9:49 AM, Joseph Abrahamson <me at jspha.com
> <mailto:me at jspha.com>> wrote:
>
>> 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
>> <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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
>> <mailto:Libraries at haskell.org>
>> >
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org <mailto: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
>
--
Andreas Abel <>< Du bist der geliebte Mensch.
Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden
andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/
More information about the Libraries
mailing list