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

Thu Feb 11 22:48:29 UTC 2016

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 at gmail.com> wrote:

> On Fri, Feb 5, 2016 at 11:29 PM, Christopher Allen <cma at bitemyapp.com>
> wrote:
>
>>
>>
>> On Fri, Feb 5, 2016 at 11:55 AM, Kyle Hanson <me at 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
> <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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160211/6443ca1b/attachment.html>