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

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.

On Tue, Feb 9, 2016 at 7:20 AM, Rustom Mody <rustompmody@gmail.com> wrote:
On Fri, Feb 5, 2016 at 11:29 PM, Christopher Allen <cma@bitemyapp.com> wrote:
 

On Fri, Feb 5, 2016 at 11:55 AM, Kyle Hanson <me@khanson.io> wrote:
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. 

Summary of the problem for others:
From Takenobu Tani
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


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).

It looks like where the discussion is going is to have these types show by default but eventually have an Alternative prelude for beginners.

From Richard Eisenberg:
- 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.
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.

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.

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.

--
Kyle


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.


Consider these two delightful pianists:  Martha and  Rose
  • Are they playing the same instruments?
  • Would they need the same teachers?
  • Ultimately, is the single moniker "pianist" meaningfully applicable to both?

I believe we are too taken with the fact that programming language theory has advanced in the last couple of decades, while we miss the fact that programming pedagogy has regressed in the same period. And one of the big regresses is the illusion that a single 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.

FP in ACM Curriculum 2013 spells out this – omnibus language – and such fallacies in more detail.

And as regards prior art regarding the benefits for multiple close but different languages for teaching, one could see the multiple teachpacks of Scheme/Racket
And even closer to home, helium is a haskell expressly designed to make teaching easier by not over-generalizing types


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe