<div dir="ltr"><div>Oh, that makes sense. If you regularly do stuff with OverlappingInstances, that can definitely bite you :) I did not think about that since I tend to avoid OverlappingInstances in my own work whenever possible. Makes sense, then!<br>

<br></div>I think it might make sense to have a list like this on a wiki somewhere, honestly. Of course a lot of bikeshedding could go into the exact division of topics, but it'd still be useful for something like this to exist somewhere.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 24, 2014 at 4:19 PM, Wojciech Danilo <span dir="ltr"><<a href="mailto:wojciech.danilo@gmail.com" target="_blank">wojciech.danilo@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Alex - we are making a very havy use of them (we are creating our own language, compiler and domain specific libraries) - but you are right - in other scenarios, they would be intermidiate (not advanced in my opinion).<div>



<br></div><div>Andrew - I would disagree with point 1. If you are using OverlappingInstances and you are defining self-recursive instances, compiler will complain giving you no hints unless you know what you are doing (again, we are making ahvy use out of it, so I'm a little biased)</div>



<div>Ad. 2) - you are right - they are in the intermediate section, because they are not hard to follow and understand. Additional, they are used a lot in reactive programming - but here I agree, they could go elsewhere.</div>



<div><br></div><div>And of course you are right - there is a bunch of very busic stuff not covered by the list - maybe I should just add it there, to make this list more pure! :D</div><div><div><br></div><div><br></div></div>



</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-25 1:14 GMT+02:00 Andrew Gibiansky <span dir="ltr"><<a href="mailto:andrew.gibiansky@gmail.com" target="_blank">andrew.gibiansky@gmail.com</a>></span>:<div>

<div class="h5"><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>The list there you have roughly corresponds to my intuitions, except for a few minor things:<br>



<br></div>1. Functional dependencies. --- I personally have used functional dependencies and wrestled with things like the coverage condition, and while I know I could easily look it up and would have no trouble understanding it, I doubt I could tell you what each of those is without looking it up. But I've never felt that knowing that is really worthwhile - they're just things the compiler will complain about if I run into them accidentally, and most programmers who have written enough of their own instances probably get them right anyways. So I'm not really sure that understanding those is necessary for being productive on a day-to-day basis, and they seem a bit out of place on that list. Do you have a particular reason they're there?<br>





<br></div>2. Arrows -- I've been programming Haskell for a few years now, and only run in to arrows <i>in practice</i> a few times. I've definitely seen a few libraries migrating away from arrows towards applicative or monadic interfaces instead. Do you use them often? I definitely feel like they're a bit more on the esoteric side, while GADTs, free monads, lenses, type families, and existential data types are things I encounter fairly frequently. On the other hand, they seem to be a good model for FRP and such, so maybe not. (Same goes for church encodings, but that's just a nice bit of CS that people should know a bit :) )<br>





<br></div>On the whole, looks like a pretty good list that I agree with. Of course, the "basic" list really includes a bunch more - knowledge of data types, syntax, functions, laziness, etc. <br><span><font color="#888888"><br>



</font></span></div><span><font color="#888888">-- Andrew<br>

<div><div><br></div></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 24, 2014 at 4:01 PM, Wojciech Danilo <span dir="ltr"><<a href="mailto:wojciech.danilo@gmail.com" target="_blank">wojciech.danilo@gmail.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is **very** interesting question! <div>When we recruit people to our company (we are working in Haskell everyday), we are basing on some classification between basic, intermediate and advanced stuff. These sections are shown below. I would love to hear what others are thinking about it and what from the below stuff would be widely considered as "basic Haskell knowledge", which would allow for full-time basic Haskell work.</div>







<div><br></div><div><h1 style="margin:0px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(0,0,0);border-bottom-color:rgb(46,61,84);font-family:Arial,sans-serif">Basics</h1><ol style="margin:10px 0px 0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:13.63636302947998px;line-height:18.18181800842285px">







<li>type classes</li><li>instances</li><li>functors, applicatives, monads, etc (<a href="http://www.haskell.org/haskellwiki/Typeclassopedia" rel="nofollow" style="color:rgb(50,108,166);text-decoration:none" target="_blank">http://www.haskell.org/haskellwiki/Typeclassopedia</a>)</li>







<li>functional dependencies</li><ol><li>Patterson condition</li><li>Coverage condition</li><li>Liberal coverage condition</li></ol><li>monad transformers</li></ol><h1 style="margin:30px 0px 0px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(0,0,0);border-bottom-color:rgb(46,61,84);font-family:Arial,sans-serif">







Intermidiate</h1><ol style="margin:10px 0px 0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:13.63636302947998px;line-height:18.18181800842285px"><li>lens</li><li>arrows</li><li>free monads</li><li>GADTs</li>







<li>Type families<ol style="margin:0px;list-style-type:lower-alpha"><li>closed type families</li></ol></li><li>existential datatypes</li><li>RankNTypes</li><li>church encoding</li></ol><h1 style="margin:30px 0px 0px;padding:0px;font-size:24px;font-weight:normal;line-height:1.25;color:rgb(0,0,0);border-bottom-color:rgb(46,61,84);font-family:Arial,sans-serif">







Advanced</h1><ol style="margin:10px 0px 0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:13.63636302947998px;line-height:18.18181800842285px"><li>templateHaskell</li><li>generics</li><li>continuations</li><li>







delimited continuations</li></ol></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-25 0:44 GMT+02:00 Johan Larson <span dir="ltr"><<a href="mailto:johan.g.larson@gmail.com" target="_blank">johan.g.larson@gmail.com</a>></span>:<div>





<div><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What does a programmer need to know to be proficient in "basic Haskell"?<br>
<br>
For my money, basic programming skills are those that are required to<br>
write programs for simple tasks in the common idioms of the language.<br>
This means the practitioner should be able to read input from the<br>
terminal or files, select/combine/reformat data, and output a result.<br>
At this point, efficiency isn't really the point; only getting to a<br>
correct answer without writing anything really weird matters.<br>
<br>
In LYAH, I'd put the boundary at the end of chapter 9, which covers<br>
the IO monad. At that point the reader has studied functions, lists,<br>
tuples, types, recursion, higher order functions, four major modules,<br>
and algebraic data types. Actually, some of the later topics in<br>
chapter 8 (functors, kinds, recursive data structures) seem more like<br>
intermediate material.<br>
<br>
Thoughts?<br>
<span><font color="#888888"><br>
--<br>
Johan Larson -- Toronto, Canada<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</font></span></blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div>