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

Fri Feb 5 23:30:12 UTC 2016

+1 for Christopher's email
Richard, I disagree with  "But it could indeed be explained to an
intermediate programmer in another language just learning Haskell." Your
explanation is good but it assumes you have already explained "types of
kind *" and the boxed vs unboxed distinction. Admittedly the latter should
be understood by most Java programmers but I doubt that intermediate
programmers in other languages do. If I did have to explain "$" I would
say, for now think of it in terms of it's pre 8.0 type. Alternatively avoid
mentioning "$" to beginners. I don't believe it is in Hutton's book or any
of Bird's although I might be wrong.

Most intermediate programmers in another language struggle a lot with
learning monads, witness all the monad tutorials. Absorbing monads is
central, there is a lot that has to be explained before that. Minimizing
that material would be a good thing.

I have mixed feelings about a beginner's prelude best summarized by saying
the proposed beginner's prelude should be the standard prelude and the
current one should be an advanced prelude. If we have a beginner's prelude
I feel we are saying that this is a hard to understand research language
and we hope that someday you have enough education, energy and tenacity to
get to the point where you understand it. If we do it the other way we are
saying you have what you need but if you want more there is lots!

On Fri, Feb 5, 2016 at 3:05 PM, Christopher Allen <cma at bitemyapp.com> wrote:

> Changing the name doesn't fix the issue. The issue is the noise and the
> referent, not the referrer. There's a habit of over-focusing on names in
> programming communities. I think it'd be a mistake to do that here and risk
> missing the point.
>
> You can make all of the keywords in the Java example salient early on, but
> you cannot make the implementation details you're exposing in the type of
> ($) relevant unless they already have a year or two of Haskell under their
> belts. Listing out the keywords:
>
> 1. public
>
> 2. class
>
> 3. (class name)
>
> 4. static
>
> 5. void
>
> 6. (method name)
>
> 7. (method arguments)
>
> Explaining public, class, static, and void usually happens pretty soon
> after the basics in a Java course. Importantly, they're things you _need_
> to know to get things done properly in Java. The same is not true of what
> is mentioned in the type of ($).
>
> The implicit prenex form and forall are irrelevant for learners until they
> get to Rank2/RankN which is very much beyond, "I am learning Haskell" and
> into, "I am designing an API in Haskell for other people to use". * vs. #
> is something many working and hobbyist Haskellers I've known will scarcely
> know anything about.
>
> There is a big difference, to my mind, between what is being exposed here
> in Java versus what is being exposed in the type ($). Consider that the
> boxed/unboxed distinction exists in Java but needn't come up in any
> beginner tutorials.
>
> >Types of kind * have values represented by pointers. This is the vast
> majority of data in Haskell, because almost everything in Haskell is boxed.
>
> We can't assume Haskell learners know what pointers are. This, again,
> creates unnecessary noise for learners by forcing exposure to things that
> are irrelevant for a very long time.
>
>
> On Fri, Feb 5, 2016 at 12:13 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>> Perhaps it will aid the discussion to see that the type of ($) will, for
>> better or worse, be changing again before 8.0.
>>
>> The problem is described in GHC ticket #11471. The details of "why"
>> aren't all that important for this discussion, but the resolution might be.
>> The new (hopefully final!) type of ($) will be:
>>
>> > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a
>> -> b
>>
>> Once again, it's easy enough to tweak the pretty-printer to hide the
>> complexity. But perhaps it's not necessary. The difference as far as this
>> conversation is concerned is that Levity has been renamed to RuntimeRep. I
>> think this is an improvement, because now it's not terribly hard to explain:
>>
>> ---
>> 1. Types of kind * have values represented by pointers. This is the vast
>> majority of data in Haskell, because almost everything in Haskell is boxed.
>> 2. But sometimes, we don't care how a value is represented. In this case,
>> we can be polymorphic in the choice of representation, just like `length`
>> is polymorphic in the choice of list element type.
>> 3. ($) works with functions whose result can have any representation, as
>> succinctly stated in the type. Note that the argument to the function must
>> be boxed, however, because the implementation of ($) must store and pass
>> the argument. It doesn't care at all about the result, though, allowing for
>> representation-polymorphism.
>>
>> In aid of this explanation, we can relate this all to Java. The reference
>> types in Java (e.g., Object, int[], Boolean) are all like types of kind *.
>> The primitive types in Java (int, boolean, char) do not have kind *. Java
>> allows type abstraction (that is, generics) only over the types of kind *.
>> Haskell is more general, allowing abstraction over primitive types via
>> representation polymorphism.
>> ---
>>
>> Could this all be explained to a novice programmer? That would be a
>> struggle. But it could indeed be explained to an intermediate programmer in
>> another language just learning Haskell.
>>
>> For point of comparison, Java is widely used as a teaching language. And
>> yet one of the simplest programs is
>>
>> public class HelloWorld
>> {
>>   public static void main(String[] args)
>>   {
>>     System.out.println("Hello, world!");
>>   }
>> }
>>
>> When I taught Java (I taught high-school full time for 8 years), I would
>> start with something similar to this and have to tell everyone to ignore
>> 90% of what was written. My course never even got to arrays and `static`!
>> That was painful, but everyone survived. This is just to point out that
>> Haskell isn't the only language with this problem. Not to say we shouldn't
>> try to improve!
>>
>> We're in a bit of a bind in all this. We really need the fancy type for
>> ($) so that it can be used in all situations where it is used currently.
>> The old type for ($) was just a plain old lie. Now, at least, we're not
>> lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain
>> growth because it affects how easy the language is to learn? I don't really
>> think anyone is advocating for (3) exactly, but it's hard to have (2) and
>> not make things more complicated -- unless we have a beginners' mode or
>> other features in, say, GHCi that aid learning. As I've said, I'm in full
>> favor of adding these features.
>>
>> Richard
>>
>> On Feb 5, 2016, at 12:55 PM, 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
>>
>>
>> On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis <
>> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>>
>>> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote:
>>> > > What's changed?
>>> >
>>> > I was referring to a discussion on ghc-devs, see
>>> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html
>>> > and mixed up addresses when replying.
>>>
>>> I'm glad you did, because this is the first I've heard of it!
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160205/26b72398/attachment-0001.html>