<div dir="ltr">Sounds reasonable. A few comments:<div><br></div><div>Avoid the temptation to think of monads as "containers" as much as possible, some containers aren't monads (Set, for example) and many monads aren't containers (IO, Reader, Writer, State, etc.).</div><div><br></div><div>As I understand "design pattern"s, they are approaches to solving problems that cannot be completely abstracted away. In that sense, "monad"s are no stranger a design pattern than "visitor".</div><div><br></div><div>Some resources (many of which could be found by searching for "haskell design patterns", but which I personally found interesting):</div><div><a href="https://scholar.google.com/scholar?cluster=4442103092796807160&hl=en&as_sdt=0,21">Design patterns for functional strategic programming</a> (discusses patterns which are found in functional programming)</div><div><a href="http://blog.ezyang.com/2010/05/design-patterns-in-haskel/">http://blog.ezyang.com/2010/05/design-patterns-in-haskel/</a> (relates the original GoF patterns to Haskell alternatives) </div><div><a href="http://www.haskellforall.com/2012/08/the-category-design-pattern.html">http://www.haskellforall.com/2012/08/the-category-design-pattern.html</a></div><div><a href="http://www.haskellforall.com/2012/09/the-functor-design-pattern.html">http://www.haskellforall.com/2012/09/the-functor-design-pattern.html</a></div><div>(more design principles than design patterns, IMO, but good, clear reads)</div><div><a href="http://dev.stephendiehl.com/hask/">http://dev.stephendiehl.com/hask/</a> (an all around amazing resource of curated material)<br></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 1:30 AM Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com">dennis.raddle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I have been using Haskell on and off, as a hobbyist, for five years. I haven't been diligent in training myself on it, so I am learning slowly. It was confusing at first, coming from an imperative background.<div><br></div><div>It occurred to me the other day that Haskell typeclasses are a kind of "design pattern." They identify a common pattern and provide a solution. I've been reading about design patterns in C++ for years. Haskell patterns are a twist on that.</div><div><br></div><div>The imperative view looks at a task in a certain way, often conceiving of it as steps that mimic how human thoughts would go, and finding big general patterns that occur in different big applications.</div><div><br></div><div>I don't want to speak for all of Haskell, but at least some Haskell patterns are smaller-scale and more attuned to the language of programming rather than the language of human thought.</div><div><br></div><div>For instance, the Monad. The common use case is this---you have some "things," and you have a "container" that can accept more than one type of "thing." The common patterns are</div><div><br></div><div>- you need to wrap things in the container</div><div>- you need to unwrap things</div><div>- you need to modify things while in their container</div><div>- you have functions that operate on containers</div><div>- you have functions that operate on the things, but maybe you don't want to unwrap them first. or maybe you do.</div><div><br></div><div>To an imperative programmer, this is bizarre. What things are you talking about? What containers? You have not defined either one, so why can you say anything specific? Why all this emphasis on wrapping and unwrapping? </div><div><br></div><div>Yet this is a design pattern all the same. It gets weird when you realize that the Maybe monad, conceived in human-thought terms, has totally different behavior than the list monad. Yet they are the same design pattern and have a relationship that is more concisely expressed mathematically than in human thought.</div><div><br></div><div>The abundance of operators for wrapping/unwrapping/operating seems, if I understand right, closely related to the conciseness of Haskell. If you can use your containers without unwrapping them first, then by all means you don't want extra syntax just to do so. Same if you have functions that only operate on unwrapped things.</div><div><br></div><div>Haskell patterns are "lightweight" also helping with the conciseness. The closest thing to a "container" in C++ is a class, which is a dozen times heavier than a Functor, Applicative, or Monad. Actually you really need a "template class" which is like a tank compared to Functor which is a skinny guy fighting with a short knife (who can usually get the job done just fine, thank you).</div><div><br></div><div>Any comments welcome. I'm just trying to get a good perspective on Haskell.</div><div><br></div><div>Mike</div><div><br></div></div>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
</blockquote></div></div></div>