<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 24, 2017 at 5:17 AM, Anthony Clayden <span dir="ltr"><<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Edward for the comprehensive reply.<br>
<br>
Yes I know Foldable isn't powerful enough to construct.<br>
I wasn't seriously proposing that as the signature.<br>
<br>
I was pointing out that there were several value judgments<br>
in arriving at the FTP changes.</blockquote><div><br></div><div>Sure. There are plenty of them to poke at. It was a big complicated messy process. I have plenty of warts I would have liked to have shaved off, but which we couldn't justify because of costs in other areas.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> Neither Foldable f nor even Traversable f give you the<br>
> power to construct a new 'f' with different shape.<br>
><br>
<br>
</span>Exactly. So why even bother with<br>
concat (Right [...]); or concat (Just [...]) ?<br>
<span class="gmail-"><br></span></blockquote><div>Because it was already there in Foldable along side a number of other combinators that are already being generalized, and there was no good reason to explicitly _exclude_ it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> concat is just a type restricted version of fold = foldMap<br>
> id provided basically for legacy compatibility.<br>
><br>
<br>
</span>OK. It's arbitrary but your justification is it was always<br>
arbitrary.<br>
FTP `concat` does the same as pre-FTP `concat`.<br>
"For legacy compatibility".<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
By that same argument:<br>
pre-FTP `length` wasn't even in Foldable.<br>
It was arbitrarily restricted to Lists.<br>
"For legacy compatibility" it should have stayed restricted<br>
to Lists.</blockquote><div><br></div><div>length/null were generalized by a separate proposal to the FTP that happened at the same time. </div><div><br></div><div>Nobody put forth such a proposal to generalize concat.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> The Foldable/Traversable proposal was to bring the<br>
> functions that already existed in base in Data.Foldable<br>
> into the Prelude and eliminate the monomorphic versions of<br>
> those combinators that made importing these more general<br>
> versions painful for users.<br>
<br>
</span>`length` was never in Data.Foldable.<br>
There was never a more general version.<br>
You're blowing smoke.</blockquote><div><br></div><div>No, I clarified that length/null generalization was a separate proposal, just later in my reply.</div><div> </div><div>I'm not assuming malice or dissimilation on your part. Please do not assume it on mine</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> A number of container types can use 'length' rather than<br>
> having to supply their own monomorphic size function.<br>
> Would 'length' have been better called 'size'?<br>
<br>
</span>Yes! Or `cardinality`.</blockquote><div><br></div><div>This runs afoul of the concern with taking new names from the Prelude which was a <b>very</b> heavy concern at the time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> That is another color the bikeshed could have been<br>
colored,<br>
<br>
</span>That's an arrogant comment.<br>
</blockquote><div><br></div><div>It wasn't dismissive. I was acknowledging that it was a different way things could have gone. We decided against it because of other concerns. There are lots of parts to this proposal that could have been concocted differently. And lots of reasons to favor one variation on the theme over another.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> but it would have involved taking a fresh name, possibly<br>
in the<br>
> Prelude, and the name collisions of a common name with<br>
> existing code was considered to be the greater evil.<br>
<br>
</span>Data.Set has `size`. It used to have `cardinality`, that was<br>
removed.<br>
OK not the Prelude, but close enough.<br>
`size` in Data.Set does exactly what `length` now does.</blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> > `concat` and `length` should not be in Foldable.<br>
> > They should be in a separate class `Consable` (say),<br>
> > which would be a sub-class of Foldable.<br>
> ><br>
><br>
> length being in such a class would mean that every author<br>
</span>..<br>
<br>
Would use a sensibly-named method (`size`) when they wanted<br>
the, er, size of a Foldable.<br>
And using `length` would document the code<br>
that they were applying to something that might be lengthy.<br></blockquote><div><br></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> While working on the Foldable/Traversable Proposal what<br>
> happened was we found we needed to add a number of methods<br>
> to the Foldable class to avoid silent changes in the<br>
> semantics of existing Haskell programs. Some Foldable<br>
> combinators folded in different directions than their<br>
> monomorphic counterparts.<br>
><br>
</span></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OK. How well communicated was that?<br>
<br>
It certainly couldn't have applied for `length`.<br>
The semantics of existing Haskell programs<br>
was that `length` worked for Lists.<br>
Only for Lists. Not Foldables in general.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>I was conveying the process by which extra surprising members wound up in Foldable at all, it doesn't directly apply to length and I was not trying to say that it did. I was trying to say why we wound up with things like sum, etc. in the class as a preamble to this next paragraph.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> Along the way as we worked to fix these infelicities and<br>
> noticed that as a side-effect that this allowed Foldable<br>
> authors some power to execute these operations with better<br>
> asymptotics where possible for their containers. This nice<br>
> knock-on effect lets folks shed some names that they were<br>
> taking from the environment by using what Prelude offers.<br>
> During this process some folks noticed that length/null<br>
> fit into the scheme,<br>
<br>
</span>Well those folks were wrong.<br>
What they should have noticed was that `size`/null fit.<br></blockquote><div><br></div><div>size would have involved taking a fresh name. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> With the choices made all of the "mainstream" base modules<br>
> now have no name conflicts and can be imported<br>
> unqualified.<br>
<br>
</span>Good. I am not criticising the FTP change in general,<br>
nor its objectives.<br>
But moving `length` from Prelude to Foldable<br>
isn't justified on those grounds.<br>
There wasn't previously a `size` (or equivalent) in<br>
Foldable.<br>
Why introduce it when there was no experience of<br>
"using for a decade" -- if that was the criterion?</blockquote><div><br></div><div>"Using it for a decade" is a short hand for saying that the bulk of the Foldable machinery had existed unchanged for a very long time. The proposal wasn't initially intended to break all that much new ground.</div><div><br></div><div>Again length/null generalization was a separate proposal that happened at the same time as FTP proper.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> Could we have named them flength (or size) and fnull so<br>
> that people had to ask for them explicitly and left<br>
> length/null alone? Yes. But it would have meant taking new<br>
> names from the Prelude or not re-exporting them from<br>
> Data.Foldable, and the AMP/FTP tried to very careful about<br>
> introducing any new names to the Prelude, and wanted users<br>
> to be able to supply instances without having to<br>
> explicitly import Data.Foldable.<br>
><br>
> We were very dubious about the response we'd get<br>
</span>> introducing new, untested, names to Prelude ...<br>
<br>
So you preferred to introduce new, unattested behaviour.<br>
<br>
`length` of an Either is unattested.<br>
`length` of a Maybe is unattested.<br>
That `length` of (1, 2) is 1 is unattested.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>Yes, and sum in Prelude previously only worked on lists, etc.</div><div><br></div><div>Little existing code was broken by the change due to it being a strict generalization. I can't say none, because length "foo" with OverloadedStrings broke.</div><div><br></div><div>If I had it to do over again? I probably would have bitten the bullet and had us take a fresh name. The outcry over fresh names turned out to be smaller than intended and the outcry over length much larger. That isn't to say I'm in a hurry to go through a second wave of breakage that churns the waters twice to fix it at this point.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So do you think it unsurprising asking for the length of a<br>
Maybe?<br>
Do you think it unsurprising that the length of (1, 2) is 1?<br></blockquote><div><br></div><div>Yes. Once you understand what Foldable is and must mean. I even _use_ these facts in concrete code that deliberately knows nothing about the Foldable/Traversable container over which it is working, when that code is put into a larger context.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Note: "length", not "size".<br></blockquote><div><br></div><div>The name could well have been size. It was a very near thing. We let the hard rule about new unnecessary names shape the proposal very heavily. In retrospect it may well have been better to accept some new names. This prevented re-export of a lot of combinators in Data.Traversable as well.</div><div><br></div><div>However, by the time such discussion could have happened everything got caught up in the drama of the massive up/down vote that was put up as a last-ditch effort to stop the whole thing. No such nuanced discussion could be heard through that noise.</div><div><br></div><div>I'm simply asking you to accept that there are some reasons on the other side o the "length" vs. "cardinality" name choice and that there is a reasonable scope for debate about which is the best to go with. The alternative was very close to having been chosen, but wasn't for the reasons I enumerated above and before. <br><br>I simply don't have a time machine, and the amount of pain involved in thrashing this design _now_ would be rather disproportionate.</div><div><br></div><div>-Edward</div></div></div></div>