<div dir="ltr">I would propose instead that two types are presented. A simple and complex type. The complex type being the most polymorphic and the simple type being the easiest to teach and explain while still not losing the concept of the operator. This way you can present what the real complex type is while also showing what it can be reduced to essentially for our current purposes<br><div><br>To those saying this would turn others off Haskell I disagree because it is similar to how we treat functions like black boxes and only identify them by type, name, and documentation. For the purposes of a beginning student they do not need to know the full type system, and thus should treat it as a black box beyond the parts which they are learning. In time one comes to understand the type system but one does not need to understand it at first.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 7:20 AM, Rustom Mody <span dir="ltr"><<a href="mailto:rustompmody@gmail.com" target="_blank">rustompmody@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">On Fri, Feb 5, 2016 at 11:29 PM, Christopher Allen <span dir="ltr"><<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</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"><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 11:55 AM, Kyle Hanson <span dir="ltr"><<a href="mailto:me@khanson.io" target="_blank">me@khanson.io</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"><div dir="ltr">I
am also happy the discussion was posted here. Although I don't teach
Haskell professionally, one of the things I loved to do was show people
how simple Haskell really was by inspecting types and slowly putting the
puzzle pieces together. <div><br></div><div>Summary of the problem for others:</div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">From <b style="font-family:-webkit-standard">Takenobu Tani</b></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Before ghc7.8:
Prelude> :t foldr
foldr :: (a -> b -> b) -> b -> [a] -> b
Prelude> :t ($)
($) :: (a -> b) -> a -> b
Beginners should only understand about following:
* type variable (polymorphism)
After ghc8.0:
Prelude> :t foldr
foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b
Prelude> :t ($)
($)
:: forall (w :: GHC.Types.Levity) a (b :: TYPE w).
(a -> b) -> a -> b</pre></div><div><br></div><div><br></div><div>With
this change it looks like I will no longer be able to keep `$` in my
toolbox since telling a beginner its "magic" goes against what I believe
Haskell is good at, being well defined and easy to understand (Not well
defined in terms of Types but well defined in terms of ability to
precisely and concisely explain and define whats going on).</div><div><br></div><div>It
looks like where the discussion is going is to have these types show by
default but eventually have an Alternative prelude for beginners.</div><div><br></div><div>From <b style="color:rgb(0,0,0);font-family:-webkit-standard">Richard Eisenberg:</b></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">- It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners.
</pre></div><div>I don't like the idea of fragmenting Haskell into
"beginners" and "advanced" versions. Its hard enough to get people to
believe Haskell is easy. If they see that they aren't using the "real"
prelude, Haskell will still be this magic black box that is too abstract
and difficult to understand. If they have to use a "dumbed down"
version of Haskell to learn, its not as compelling.</div><div><br></div><div>There
is something powerful about using the same idiomatic tools as the "big
boys" and have the tools still be able to be easy to understand.... by
default. Adding complexity to the default Haskell runs the risk of
further alienating newcomers to the language who have a misconception
that its too hard.</div><div><br></div><div>Admittedly, I am not well
informed of the state of GHC 8.0 development and haven't had time to
fully look into the situation. I am very interested to see where this
conversation and the default complexity of Haskell goes.</div><div><br></div><div>--</div><div>Kyle</div><div><br></div></div><br></blockquote></div></div></div></div></blockquote><div class="gmail_extra"><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">I don't want, nor do I think it's a good idea, to have a beginners' Prelude. My point about ($) was not expressly about beginners, it was about intermediate practitioners too.</div></blockquote><div><br><br>Consider these two delightful pianists: <a href="https://www.youtube.com/watch?v=YLZLp6AcAi4" target="_blank">Martha</a> and <a href="https://www.youtube.com/watch?v=_bjKDJD-CLc" target="_blank">Rose</a><br></div><ul><li>Are they playing the same instruments?</li><li>Would they need the same teachers?</li><li>Ultimately, is the single moniker "pianist" meaningfully applicable to both?</li></ul><div><br></div><div>I believe we are too taken with the fact that programming language <i>theory</i> has advanced in the last couple of decades, while we miss the fact that programming <i>pedagogy</i> has regressed in the same period. And one of the big regresses is the illusion that a <i>single </i>language that spans the spectrum from beginner learning to serious software engineering is a neat idea: a grand unified/universal language. Such a language already exists -- C++. An earlier generation called it PL-1.<br><br><a href="http://blog.languager.org/2015/06/functional-programming-moving-target.html" target="_blank">FP in ACM Curriculum 2013</a> spells out this – omnibus language – and such fallacies in more detail.<br><br></div><div>And as regards prior art regarding the benefits for multiple close but different languages for teaching, one could see the <a href="http://docs.racket-lang.org/teachpack/index.html?q=" target="_blank">multiple teachpacks</a> of Scheme/Racket<br></div><div>And even closer to home, <a href="http://www.open.ou.nl/bhr/heeren-helium.pdf" target="_blank">helium</a> is a haskell expressly designed to make teaching easier by not over-generalizing types<br></div><div><br></div></div>
</div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>