<html><head></head><body>For what it's worth, when starting out I found the disconnect between list sugar and list constructor/destructors extremely confusing.<br> In retrospect it seems pretty silly, but I could not figure out how lists were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes like [x, xs] were common.<br> When I finally realized that I could construct lists with the list constuctors, I started using them exclusively.<br><br>Simplcity and straightforwardness help understanding. It was much easier for me to understand a singleton list as (x : []) than [x]. Having to deal with '(singleton x)' (at the time not knowing the definition of 'singleton') would have been another layer of confusion.<br><br>I get that 'singleton' is library design, since in shows up in Map, Array, Set, etc. But for me trying to use lists, it would have only been useful if I defined it myself as a way to learn that constuctors are fuctions, and that 'singleton' means 'single'.<br><br><div class="gmail_quote">On August 23, 2019 7:56:41 AM UTC, Sven Panne <svenpanne@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div dir="ltr">Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe <<a href="mailto:kris.nuttycombe@gmail.com">kris.nuttycombe@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr"> I think there's a significant difference between "little helper" and "the monomorphic function that is used to implement `pure`" - with a slightly different framing, we might be able to come to an agreement that both the monomorphic an polymorphic versions of this function are useful in different contexts. [...]<br></div></div></div></blockquote></div></div></blockquote><div><br></div><div>I think we can agree that we disagree here. ;-) My brain is too small to remember the names of myriads of trivial helpers, so I very much prefer general, orthogonal things. In our case: If we have a general, polymorphic function (often from a type class), just use that. If for some reason (rarely!) I want a more monomorphic function, I can just add a plain old type signature somewhere (no need for funky language extensions like type applications). This radically reduces the number of things one has to remember. In our case: Know type classes + know a way to make things more monomorphic.</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"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr"></div></div></div></blockquote><div>My guiding principle for API design is that one should always expose the fundamental building blocks as a low-level API, and then provide a smaller interface for the common use cases. Typeclass instances are no different - they are the general interface that allows us to invoke what is ultimately a monomorphic, low-level building block function in a polymorphic context. </div></div></div></blockquote><div><br></div><div>This is exactly the opposite API design principle I have: Do not expose the monomorphic functions if they are already in a type class. You can easily reconstruct them as a library user via type signtures if this is really needed (still haven't seen many convincing examples of that), but you can' do it the other way round. Less things exposed, no generality/use cases lost => easier to remember.</div><div><br></div><div>The thing we can probably agree on: API design is hard and it's not an exact science, more a kind of art which is assessed in a subjective way... :-)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
</blockquote></div><br>Keith<br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>