Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

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 wrote:

On Fri, Feb 5, 2016 at 11:29 PM, Christopher Allen wrote:

...

On Fri, Feb 5, 2016 at 11:55 AM, Kyle Hanson 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 https://www.youtube.com/watch?v=YLZLp6AcAi4 and Rose https://www.youtube.com/watch?v=_bjKDJD-CLc

- 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 http://blog.languager.org/2015/06/functional-programming-moving-target.html 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 http://docs.racket-lang.org/teachpack/index.html?q= of Scheme/Racket And even closer to home, helium http://www.open.ou.nl/bhr/heeren-helium.pdf 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