<div dir="ltr">dup is nice, but i dont really care what we call it as long as its not annoying or dumbe :)</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 28, 2018 at 6:22 PM Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have no strong preference for the name for 'jam', merely the existence of the dual construction if we're going to name one.<br><br>However a needless name conflict with duplicate from Control.Comonad would be rather unfortunate.<div><br>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.<br><br></div><div>-Edward</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 28, 2018 at 6:15 PM Oliver Charles <<a href="mailto:ollie@ocharles.org.uk" target="_blank">ollie@ocharles.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jam? Seriously? I'm sure we can do much better wrt names than that.<br>
Even dup I'd rather see expanded to "duplicate". The theory might have<br>
shown that these are useful combinators, but that doesn't mean they<br>
should decide the names.<br>
On Sun, Oct 28, 2018 at 10:10 PM Edward Kmett <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br>
><br>
> If we're going to add this we should add the symmetric operation for<br>
><br>
> jam :: Either a a -> a<br>
><br>
> to Data.Either. (Name taken from Conal's compiling to categories code.)<br>
><br>
> My own code has called these diag and codiag respectively. I happily yield to a nicer convention.<br>
><br>
> 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.<br>
><br>
> -Edward<br>
><br>
> On Sun, Oct 28, 2018 at 12:07 PM Ivan Perez <<a href="mailto:ivan.perez@keera.co.uk" target="_blank">ivan.perez@keera.co.uk</a>> wrote:<br>
>><br>
>> On 28/10/18 09:48, Vanessa McHale wrote:<br>
>> > According to GHCi,<br>
>> ><br>
>> > λ:> import Control.Arrow<br>
>> > λ:> :t (id &&& id)<br>
>> > (id &&& id) :: b -> (b, b)<br>
>> ><br>
>> > That is, this implementation has type a -> (a, a) as well.<br>
>> Yes, yes, that's what I meant by "it works for functions as well (since<br>
>> they are arrows)"<br>
>><br>
>> Ivan<br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>