
I have no strong preference for the name for 'jam', merely the existence of
the dual construction if we're going to name one.
However a needless name conflict with duplicate from Control.Comonad would
be rather unfortunate.
dup as the name for this operation has a ton of precedent in languages like
forth, and its length is comparable to the already smashed fst and snd.
-Edward
On Sun, Oct 28, 2018 at 6:15 PM Oliver Charles
jam? Seriously? I'm sure we can do much better wrt names than that. Even dup I'd rather see expanded to "duplicate". The theory might have shown that these are useful combinators, but that doesn't mean they should decide the names. On Sun, Oct 28, 2018 at 10:10 PM Edward Kmett
wrote: If we're going to add this we should add the symmetric operation for
jam :: Either a a -> a
to Data.Either. (Name taken from Conal's compiling to categories code.)
My own code has called these diag and codiag respectively. I happily
yield to a nicer convention.
I have no real preference for whether we do the simple version in
Data.Tuple (which has a lot of precedent, as Data.Tuple tends to have lots of little simple combinators that could be done more generally as arrows) or moving it into Control.Arrow.
-Edward
On Sun, Oct 28, 2018 at 12:07 PM Ivan Perez
wrote:
According to GHCi,
λ:> import Control.Arrow λ:> :t (id &&& id) (id &&& id) :: b -> (b, b)
That is, this implementation has type a -> (a, a) as well. Yes, yes, that's what I meant by "it works for functions as well (since
On 28/10/18 09:48, Vanessa McHale wrote: they are arrows)"
Ivan _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries