<div dir="ltr">Apologies for being unclear. By marginal, I meant that I expect many learners who end up confused by this would have otherwise come across the same confusion by other paths. So, the long-run net amount of confusion would be the same. That's obviously a complete guess on my part, but it does seem somewhat reasonable. Learners definitely have to understand the difference between lists and tuples at some point. They also ought to understand how constructor classes work at some point. If we want to reduce the friction in that process, we should focus our energy on creating better educational material, not on removing certain instances that we think are particularly opaque.<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 3:24 PM, Henrik Nilsson <span dir="ltr"><<a href="mailto:Henrik.Nilsson@nottingham.ac.uk" target="_blank">Henrik.Nilsson@nottingham.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>Hi,</div>
<div><br>
</div>
<div>Sorry Nathan, I am not following your argument: you seem to be arguing two ways at the same time. Maybe "marginal" should have been "major"?</div>
<div><br>
</div>
<div>However:</div><span class="">
<div><br>
</div>
<div>> I see an additional way for an unwary</div>
<div>> learner to discover complexity that </div>
<div>> was already there, by passing a value</div>
<div>> that they weren't previously able to </div>
<div>> pass to a function</div>
<div><br>
</div>
</span><div>No, that specific complexity were *not* there previously. Applying length or maximum etc. to a tuple used to be a type error. End of story. And that was a good thing for many reasons, including that length or maximum on tuples are not particularly useful:
the former being a roundabout way to compute 1, the latter being a rather obscurely named projection function.</div></div></blockquote><div><br></div><div>One could similarly argue that `id` is not particularly useful, being a roundabout way to compute something you already have.</div><div><br></div><div>We're clearly talking about different specific complexities. As I see it, the complexity is in how constructor classes work (as Chris helpfully pointed out). They work the same regardless of what instance of them you focus on. If a learner happens to come across their existence sooner because they accidentally called length on a tuple and became confused, we can either 1) take the opportunity to teach them about a useful concept, or 2) postpone the explanation for later. In either case, the concept itself is exactly as complex as it ever was.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span class="">
<div><br>
</div>
<div>/Henrik</div>
<div><br>
</div>
Henrik Nilsson
<div>School of Computer Science</div>
<div>The University of Nottingham</div>
<div><a href="mailto:nhn@cs.nott.ac.uk" target="_blank">nhn@cs.nott.ac.uk</a></div>
<div><br>
</div>
<div></div>
<br>
<br>
-------- Original message --------<br>
From: Nathan Bouscal <br></span><div><div class="h5">
Date:2016/02/24 14:42 (GMT+00:00) <br>
To: Haskell Libraries <br>
Subject: Re: Haskell Foldable Wats (Was: Add conspicuously missing Functor instances for tuples)
<br>
<br>
<div>
<div dir="ltr">I don't see any additional complexity. I see an additional way for an unwary learner to discover complexity that was already there, by passing a value that they weren't previously able to pass to a function that they don't yet have a complete
model of. That will definitely cause some confusion, but I'm not convinced it will cause marginal confusion, nor that such confusion is bad. This is not the only way that learners can mix up tuples and lists, and that distinction is something every learner
has to understand at some point.
<div><br>
</div>
<div>You can still teach tuples exactly the same way that you used to teach tuples, and you can still teach finding the length of a list exactly the same way that you used to teach it. Unless your curriculum previously included an explicit demonstration of
`length (1, 2)` causing an error, I don't see why it would need to change.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Feb 24, 2016 at 2:20 PM, Henrik Nilsson <span dir="ltr">
<<a href="mailto:Henrik.Nilsson@nottingham.ac.uk" target="_blank">Henrik.Nilsson@nottingham.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>I am totally with Lennart here: something that used to be conceptually very simple, clear, and, not the least, easy to teach, has become complex and muddled for little if any good reason at all. What is that if not obfuscation? </div>
<div><br>
</div>
<div>And I am not just drawing on my own experience here, but also from that of many colleagues with years and years of teaching experience. </div>
<span><font color="#888888">
<div><br>
</div>
<div>/Henrik</div>
</font></span><span>
<div><br>
</div>
<div><br>
</div>
Henrik Nilsson
<div>School of Computer Science</div>
<div>The University of Nottingham</div>
<div><a href="mailto:nhn@cs.nott.ac.uk" target="_blank">nhn@cs.nott.ac.uk</a></div>
<div><br>
</div>
<div></div>
<br>
<br>
</span>
<div>
<div>-------- Original message --------<br>
From: Nathan Bouscal <br>
Date:2016/02/24 13:43 (GMT+00:00) <br>
To: Haskell Libraries <br>
Subject: Re: Haskell Foldable Wats (Was: Add conspicuously missing Functor instances for tuples)
<br>
<br>
<div>
<div dir="ltr">I'm not trying to say that a pair is not a container of two things. I'm saying that that description is insufficiently specific to be useful for the purposes of the discussion. There are many ways to be a container of two things, and if we are
to have functions whose behavior depends on the structure of the data they're working on, it's inevitable that those functions will behave differently for different of those ways of being a container. If the issue is that "containers" don't always behave the
way one might naively expect containers to behave, then I'm just pointing out that this isn't the only place that holds, and that in other areas we've already accepted this.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Feb 24, 2016 at 1:38 PM, Augustsson, Lennart <span dir="ltr">
<<a href="mailto:Lennart.Augustsson@sc.com" target="_blank">Lennart.Augustsson@sc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Of course a pair is a container of two things (which can have different types).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">You can come up with some different definition of what it means to be a container, so that a pair is no longer a container of two things, but this is just
obfuscation.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Libraries [mailto:<a href="mailto:libraries-bounces@haskell.org" target="_blank">libraries-bounces@haskell.org</a>]
<b>On Behalf Of </b>Nathan Bouscal<br>
<b>Sent:</b> 24 February 2016 13:29<br>
<b>To:</b> Haskell Libraries<span><br>
<b>Subject:</b> Re: Haskell Foldable Wats (Was: Add conspicuously missing Functor instances for tuples)<u></u><u></u></span></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Wed, Feb 24, 2016 at 1:04 PM, Henrik Nilsson <<a href="mailto:Henrik.Nilsson@nottingham.ac.uk" target="_blank">Henrik.Nilsson@nottingham.ac.uk</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Hi,<br>
<br>
On 02/24/2016 11:08 AM, Fumiaki Kinoshita wrote:<u></u><u></u></p>
<p class="MsoNormal">Thinking tuples of as multi-element containers is not recommended. A<br>
tuple (a, b) is, a pair of one 'a' and one 'b';<u></u><u></u></p>
<p class="MsoNormal"><br>
Which, to me, at least, very much sounds like a container of two<br>
elements?<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">You can use essentially the same argument to say that [a] sounds like a container of any number of elements, therefore there shouldn't be anything wrong with [1, 'foo']. It's not uncommon in programming for "what a thing naively sounds
like" to be quite different from "what a thing actually is". <i>Tuples are not lists</i>.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I agree that there's room for confusion, but there is room for confusion in
<i>a lot</i> of parts of Haskell, especially for people who bring a lot of preconceived notions with them. We should try to make the transition easier for them, but to me that looks a lot more like "really good error messages" and less like pointedly ignoring
the structure of types that might be confusing.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:4.8pt">
<br>
Seriosuly, if, as a result of tuples being instances of Functor and<br>
Foldable etc., the end result is confusion to the point that<br>
many no longer understand a tuple simply as a container of a certain<br>
number of elements, then that's another case in point against<br>
this whole design. (In particular the Foldable part: while I personally<br>
don't find the functor instances particularly compelling or useful,<br>
they seem less likely to seriously bite.)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:4.8pt">as Foldable works on<br>
values pointed by the rightmost type argument, 1 should be the only<br>
reasonable result of 'length'.<br>
<br>
data TwoThree a b = TwoThree a a b b b<br>
<br>
What should 'length (TwoThree "Foo" "Bar" 0 1 2)' be?<u></u><u></u></p>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:4.8pt">
<br>
A static type error, perhaps?<br>
<br>
(As indeed it will be unless the appropriate instances are made<br>
for TwoThree. But I am guessing we should understand TwoThree<br>
as a tuple here.)<u></u><u></u></p>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:4.8pt">
Looking at only<br>
the expression, 5 might seem to make sense, but is not meaningful<br>
considering the type.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:4.8pt"><br>
Best,<br>
<br>
/Henrik<br>
-- <br>
Henrik Nilsson<br>
School of Computer Science<br>
The University of Nottingham<br>
<a href="mailto:nhn@cs.nott.ac.uk" target="_blank">nhn@cs.nott.ac.uk</a><br>
<br>
<br>
<br>
<br>
This message and any attachment are intended solely for the addressee<br>
and may contain confidential information. If you have received this<br>
message in error, please send it back to me, and immediately delete it. <br>
Please do not use, copy or disclose the information contained in this<br>
message or in any attachment. Any views or opinions expressed by the<br>
author of this email do not necessarily reflect the views of the<br>
University of Nottingham.<br>
<br>
This message has been checked for viruses but the contents of an<br>
attachment may still contain software viruses which could damage your<br>
computer system, you are advised to perform your own checks. Email<br>
communications with the University of Nottingham may be monitored as<br>
permitted by UK legislation.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:4.8pt"><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" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<br clear="both">
<span>This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC,
Standard Chartered Bank and their subsidiaries at <a href="http://www.standardchartered.com/en/incorporation-details.html" target="_blank">
http://www.standardchartered.com/en/incorporation-details.html</a><br>
<br>
Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation
or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at
<a href="http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx" target="_blank">
http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx</a><br>
<br>
Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction.
We may at times also request you to sign on the term sheet to acknowledge in respect of the same.<br>
<br>
Please visit <a href="http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx" target="_blank">
http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx</a> for important information with respect to derivative products.<br>
</span></div>
</blockquote>
</div>
<br>
</div>
</div>
<pre>This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.
Please do not use, copy or disclose the information contained in this
message or in any attachment. Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.
This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.
</pre>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<pre>This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.
Please do not use, copy or disclose the information contained in this
message or in any attachment. Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.
This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.
</pre></div></div></div>
</blockquote></div><br></div></div>