<div>It *is* actually a useful instance and it is used in practice. It's not that better Haskell wouldn't have an biased pair type with these instances, it's that it would *also* have an unbiased one with the instances that such a type could support. The issue seems to be that people don't like the biased type having special syntax that wrongly gives an unknowing reader the impression that the type is unbiased. This is a reasonable position, but getting rid of the tuple instances isn't a reasonable way to act on that position: 1) they're going to be defined anyway, but also 2) it's not helpful to just pretend the type is unbiased when it isn't. It would be coherent to argue for the removal of the special tuple syntax (though coherent doesn't mean reasonable; this would break everything), but it's not coherent to argue for crippling tuples so we can pretend they're something they aren't. </div><div><br></div><div><br><div class="gmail_quote"><div>On Thu, Apr 6, 2017 at 11:17 AM <<a href="mailto:amindfv@gmail.com">amindfv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
> El 6 abr 2017, a las 08:52, Ivan Lazar Miljenovic <<a href="mailto:ivan.miljenovic@gmail.com" class="gmail_msg" target="_blank">ivan.miljenovic@gmail.com</a>> escribió:<br class="gmail_msg">
><br class="gmail_msg">
>> On 6 April 2017 at 23:56,  <<a href="mailto:amindfv@gmail.com" class="gmail_msg" target="_blank">amindfv@gmail.com</a>> wrote:<br class="gmail_msg">
>> I don't totally understand this viewpoint. It sounds like what you're saying<br class="gmail_msg">
>> is it's unfortunate that tuples (and everything else) are biased in Haskell,<br class="gmail_msg">
>> but because they are we're obligated to make all the legal instances we can<br class="gmail_msg">
>> for them.<br class="gmail_msg">
>><br class="gmail_msg">
>> E.g. if I define a datatype "data Foo x y z", I'm powerless and sort of<br class="gmail_msg">
>> obligated to define "instance Functor (Foo x y)" if there's a legal one,<br class="gmail_msg">
>> regardless of if that's what I want Foo to mean.<br class="gmail_msg">
><br class="gmail_msg">
> Is Foo going to be widely used or only an internal data type to your own code?<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
For the sake of comparison, let's say it's going to be widely used. It's also a structure which isn't (conceptually) biased.<br class="gmail_msg">
<br class="gmail_msg">
If we're starting from a place of feeling that it's a shame Haskell is unable to have unbiased structures, then probably an "if we knew then what we know now" version of Haskell would have them. So then why knowingly create instances we think a "better Haskell" wouldn't have?<br class="gmail_msg">
<br class="gmail_msg">
Is the argument that if it's public-facing, someone's going to define the instance and so we should do it canonically? If so, this feels to me a little like "you can't fire me, I quit!" - doing what we don't want before someone else has a chance to.<br class="gmail_msg">
<br class="gmail_msg">
Tom<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
>><br class="gmail_msg">
>> Tom<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> El 3 abr 2017, a las 15:29, Nathan Bouscal <<a href="mailto:nbouscal@gmail.com" class="gmail_msg" target="_blank">nbouscal@gmail.com</a>> escribió:<br class="gmail_msg">
>><br class="gmail_msg">
>> I expect most people probably agree that it'd be nice to have tuples be an<br class="gmail_msg">
>> unbiased cartesian product, but the actual fact of the matter is that tuples<br class="gmail_msg">
>> as they exist in Haskell are biased. We can't just ignore that and pretend<br class="gmail_msg">
>> they're unbiased. It definitely sucks that the answer people would naively<br class="gmail_msg">
>> give to "what is a tuple in Haskell" is not the correct answer, but we're<br class="gmail_msg">
>> stuck in that situation. The question is how to make the best of it.<br class="gmail_msg">
>><br class="gmail_msg">
>> On Mon, Apr 3, 2017 at 12:56 PM, Henning Thielemann<br class="gmail_msg">
>> <<a href="mailto:lemming@henning-thielemann.de" class="gmail_msg" target="_blank">lemming@henning-thielemann.de</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>>> On Mon, 3 Apr 2017, Sven Panne wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> Of course such an interpretation is possible, but let's remember<br class="gmail_msg">
>>>> Abelson's famous quote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>>   "Programs must be written for people to read, and only incidentally<br class="gmail_msg">
>>>> for machines to execute."<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> When you show somebody a pair and ask "What is this?", how many people do<br class="gmail_msg">
>>>> you *seriously* expect to say "Oh, yeah, I've seen that: It's a value on the<br class="gmail_msg">
>>>> right decorated by another one on the left!" compared to people telling you<br class="gmail_msg">
>>>> something about e.g. cartesian products (which are totally symmetric with no<br class="gmail_msg">
>>>> bias to the right or left)? The point is: Using a pair for a decorated<br class="gmail_msg">
>>>> one-element container is completely miscommunicating your intent, even if<br class="gmail_msg">
>>>> you find a sensible mathematical interpretation for it.<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> That's what I am saying all the time.<br class="gmail_msg">
>>> _______________________________________________<br class="gmail_msg">
>>> Libraries mailing list<br class="gmail_msg">
>>> <a href="mailto:Libraries@haskell.org" class="gmail_msg" target="_blank">Libraries@haskell.org</a><br class="gmail_msg">
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> Libraries mailing list<br class="gmail_msg">
>> <a href="mailto:Libraries@haskell.org" class="gmail_msg" target="_blank">Libraries@haskell.org</a><br class="gmail_msg">
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> Libraries mailing list<br class="gmail_msg">
>> <a href="mailto:Libraries@haskell.org" class="gmail_msg" target="_blank">Libraries@haskell.org</a><br class="gmail_msg">
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" class="gmail_msg" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> --<br class="gmail_msg">
> Ivan Lazar Miljenovic<br class="gmail_msg">
> <a href="mailto:Ivan.Miljenovic@gmail.com" class="gmail_msg" target="_blank">Ivan.Miljenovic@gmail.com</a><br class="gmail_msg">
> <a href="http://IvanMiljenovic.wordpress.com" rel="noreferrer" class="gmail_msg" target="_blank">http://IvanMiljenovic.wordpress.com</a><br class="gmail_msg">
</blockquote></div></div>