Pre-Proposal: Add Validation somewhere easily accessible

newer
Proposal (long term): Remove (/=)...

older
Proposal: Add a few extra members...

Joseph Abrahamson

21 Sep 2014 21 Sep '14

1:05 p.m.

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

Attachments:

attachment.html (text/html — 2.8 KB)

Show replies by date

Henning Thielemann

21 Sep 21 Sep

1:14 p.m.

On Sun, 21 Sep 2014, Joseph Abrahamson 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.

I would define it as you did above. Left and Right constructors of Either are not very descriptive.

...

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.

My first choice would be 'transformers' because I already import this extensively. Second choice would be any other package that is plain Haskell 98 for portability reasons.

Edward Kmett

1:17 p.m.

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" 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Joseph Abrahamson

1:51 p.m.

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 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" 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Greg Weber

2:05 p.m.

The errors package seems like a good location for it. On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson 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 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" 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Joseph Abrahamson

4:56 p.m.

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 wrote:

...

The errors package seems like a good location for it. On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson 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 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" 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Edward Kmett

22 Sep 22 Sep

10:38 a.m.

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 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 wrote:

...
The errors package seems like a good location for it.

On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson 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 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" 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Michael Snoyman

10:41 a.m.

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 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 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 wrote:

...
The errors package seems like a good location for it.

On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson 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 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" 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Joseph Abrahamson

10:49 a.m.

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 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 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 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 wrote:

...
The errors package seems like a good location for it.

On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson 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 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" 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@haskell.org > http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Chris Allen

11:11 a.m.

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 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 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 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 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 wrote: The errors package seems like a good location for it.

...
On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson 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 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" 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@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Andreas Abel

11:43 a.m.

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-App... 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-Applic... 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 mailto:me@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 mailto:michael@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 mailto:ekmett@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 mailto:me@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 mailto:greg@gregweber.info> wrote:

The errors package seems like a good location for it.

On Sun, Sep 21, 2014 at 10:51 AM, Joseph Abrahamson mailto:me@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 mailto:ekmett@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" mailto:me@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@haskell.org mailto:Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@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@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Roman Cheplyaka

3:13 p.m.

On 22/09/14 18:43, Andreas Abel wrote:

...

UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

Brilliant, thanks a lot! For me, having it in transformers outweighs all the benefits that a separate package may provide (especially a package as heavy as 'errors'). Roman

Edward Kmett

7:12 p.m.

Lift is rather different than Validation. On Mon, Sep 22, 2014 at 3:13 PM, Roman Cheplyaka wrote:

...

On 22/09/14 18:43, Andreas Abel wrote:

...
UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

Brilliant, thanks a lot! For me, having it in transformers outweighs all the benefits that a separate package may provide (especially a package as heavy as 'errors').

Roman

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Joseph Abrahamson

7:27 p.m.

`Lift` is, but `Errors` should be identical, correct? It appears to work exactly as I would hope in my testing, anyway. The only difference is one further step unwrapping the Constant. Am I missing something major? Tangentially, I don’t understand why transformers defines its own Constant type, though, given Const in Applicative. At least in transformers 4.0 they use the built-in Eq1 classes and the like. Joseph On Mon, Sep 22, 2014 at 7:12 PM, Edward Kmett wrote:

...

Lift is rather different than Validation. On Mon, Sep 22, 2014 at 3:13 PM, Roman Cheplyaka wrote:

...
On 22/09/14 18:43, Andreas Abel wrote:

...
UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

Brilliant, thanks a lot! For me, having it in transformers outweighs all the benefits that a separate package may provide (especially a package as heavy as 'errors').

Roman

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Edward Kmett

8:17 p.m.

There was some discussion of retiring Constant, as it is mostly unused, and Const has supplanted it in common usage. It didn't happen with this last release of transformers. -Edward On Mon, Sep 22, 2014 at 7:27 PM, Joseph Abrahamson wrote:

...

`Lift` is, but `Errors` should be identical, correct? It appears to work exactly as I would hope in my testing, anyway. The only difference is one further step unwrapping the Constant. Am I missing something major?

Tangentially, I don’t understand why transformers defines its own Constant type, though, given Const in Applicative. At least in transformers 4.0 they use the built-in Eq1 classes and the like.

Joseph

On Mon, Sep 22, 2014 at 7:12 PM, Edward Kmett wrote:

...
Lift is rather different than Validation.

On Mon, Sep 22, 2014 at 3:13 PM, Roman Cheplyaka wrote:

...
On 22/09/14 18:43, Andreas Abel wrote:

...
UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

Brilliant, thanks a lot! For me, having it in transformers outweighs all the benefits that a separate package may provide (especially a package as heavy as 'errors').

Roman

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Gershom B

10:29 p.m.

I wrote some about Lift, etc. back in this comonad reader post: http://comonad.com/reader/2012/abstracting-with-applicatives/ Note that I give a more general construction than Lift, in that it produces an applicative for any Sum with an appropriate natural transformation. Note that Lift Const arises both from the initial homomorphism that sends identity to anything, and the terminal homomorphism that sends everything to const. I’m not advocating moving any of the things described in that post into transformers or the like (certainly not at the moment), but for those interested in how we build these things up, and where they come from, the post may be of some interest. Cheers, Gershom On September 22, 2014 at 8:17:44 PM, Edward Kmett (ekmett@gmail.com) wrote:

...

There was some discussion of retiring Constant, as it is mostly unused, and Const has supplanted it in common usage. It didn't happen with this last release of transformers.

-Edward

On Mon, Sep 22, 2014 at 7:27 PM, Joseph Abrahamson wrote:

...
`Lift` is, but `Errors` should be identical, correct? It appears to work exactly as I would hope in my testing, anyway. The only difference is one further step unwrapping the Constant. Am I missing something major?

Tangentially, I don’t understand why transformers defines its own Constant type, though, given Const in Applicative. At least in transformers 4.0 they use the built-in Eq1 classes and the like.

Joseph

On Mon, Sep 22, 2014 at 7:12 PM, Edward Kmett wrote:

...
Lift is rather different than Validation.

On Mon, Sep 22, 2014 at 3:13 PM, Roman Cheplyaka wrote:

...
On 22/09/14 18:43, Andreas Abel wrote:

...
UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

Brilliant, thanks a lot! For me, having it in transformers outweighs all the benefits that a separate package may provide (especially a package as heavy as 'errors').

Roman

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Michael Snoyman

11:52 p.m.

I may have misread, but it seems like Errors is isomorphic to Validation. Nonetheless, I'd still support having something like Validation in the either package, as I'm certain the error messages that would result from using Errors would be atrocious, making it a non-starter for many use cases. On Tue, Sep 23, 2014 at 2:12 AM, Edward Kmett wrote:

...

Lift is rather different than Validation.

On Mon, Sep 22, 2014 at 3:13 PM, Roman Cheplyaka wrote:

...
On 22/09/14 18:43, Andreas Abel wrote:

...
UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

Brilliant, thanks a lot! For me, having it in transformers outweighs all the benefits that a separate package may provide (especially a package as heavy as 'errors').

Roman

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Henning Thielemann

4:05 p.m.

On Mon, 22 Sep 2014, Andreas Abel wrote:

...

UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

seems to be doing the job of "Validation" already (no nice names of the operations, though).

Well spotted! For me this is enough of a solution.

Joseph Abrahamson

4:08 p.m.

Andreas, that’s perfect! I had never realized the solution was sitting under my nose the whole time. Indeed, for my purposes—basically any time I’ve used this type—this is by far the best solution. It’s more than enough for me to just withdrawal any desire to make a concrete proposal. Thanks for the discussion everyone. Joseph On Mon, Sep 22, 2014 at 4:05 PM, Henning Thielemann wrote:

...

On Mon, 22 Sep 2014, Andreas Abel wrote:

...
UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

seems to be doing the job of "Validation" already (no nice names of the operations, though). Well spotted! For me this is enough of a solution.

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Ross Paterson

24 Sep 24 Sep

3:06 p.m.

On Mon, Sep 22, 2014 at 05:43:05PM +0200, Andreas Abel wrote:

...

UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

seems to be doing the job of "Validation" already (no nice names of the operations, though).

Which operations and names would you like?

Andreas Abel

25 Sep 25 Sep

3:52 a.m.

To use the Errors type in a nice way: * I'd like to import it from a module named Control.Applicative.Error(s) * be able to work it without reference to Lift, Constant, Pure, Other. The second point would amout to, I guess, * newtype Errors instead of type Errors * having 'runErrors' that give me the result or the errors. Just some initial thoughts, Andreas On 24.09.2014 21:06, Ross Paterson wrote:

...

On Mon, Sep 22, 2014 at 05:43:05PM +0200, Andreas Abel wrote:

...
UPDATE: I found that "Errors e" on

https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Applic...

seems to be doing the job of "Validation" already (no nice names of the operations, though).

Which operations and names would you like?

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

3891

Age (days ago)

3895

Last active (days ago)

List overview

Download

20 comments

10 participants

participants (10)

Andreas Abel
Chris Allen
Edward Kmett
Gershom B
Greg Weber
Henning Thielemann
Joseph Abrahamson
Michael Snoyman
Roman Cheplyaka
Ross Paterson