Re: New type of ($) operator in GHC 8.0 is problematic

Yes, the inference of call-stacks is being removed. I'm just waiting for the patch to be reviewed. On Mon, Mar 28, 2016, at 06:22, George Colpitts wrote: > Was there any consensus on how to move forward on this? I just found > another example of > ​​ > 8.0 type which is not beginner friendly: >

Re: New type of ($) operator in GHC 8.0 is problematic

Was there any consensus on how to move forward on this? I just found another example of ​​ 8.0 type which is not beginner friendly: bash-3.2$ ghci GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> True True it :: Bool Prelude> True || undefined True *it ::

Re: New type of ($) operator in GHC 8.0 is problematic

I dispute your second point a bit: I consider any Prelude changes a standard library change than a language change, not withstanding the fact the Prelude is imported by default. Any beginner-language library can still be imported from normal code. Likewise a "hygienic copy paste" would simply

Re: New type of ($) operator in GHC 8.0 is problematic

Two notable differences between Racket and the situation in Haskell is that (1) Racket has a full blown IDE to support the staged languages and (2) AFIK any Racket program in a simpler language is still a valid Racket program in a more advanced language. (The latter wouldn’t be the case with,

Re: New type of ($) operator in GHC 8.0 is problematic

Hi, I know the issue of beginner's Prelude. But how about "profile"? (like H264/MPEG4-AVC profile [1]) * Beginner Profile : beginner's Prelude or ghci beginner's representation mode * Main Profile : Haskell 2010 standard * Leading edge Profile : set of GHC extensions If

Re: New type of ($) operator in GHC 8.0 is problematic

Hi Manuel, > I do worry about the same thing. The Haskell ecosystem is very much geared towards experts and tinkerers (with laudable exceptions, such as, for example, the great work done by Chris Allen). Being an expert and tinkerer that didn’t worry me too much, but lately I am trying to make

Re: New type of ($) operator in GHC 8.0 is problematic

On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote: > I have tried a beginner's Prelude with people. I don't have a lot of data > because it was clearly a failure early on so I bailed them out into the > usual thing. It's just not worth it and it deprives them of the > preparedness to go

Re: New type of ($) operator in GHC 8.0 is problematic

Hi Takenobu, > Takenobu Tani : > > Hi Manuel, > > > * Introduce the concept of overloading right away. People get that easily, > > because they use overloaded arithmetic functions in math, too. > > (Num and Show are the typical classes to explain it at.) > > As an

Re: New type of ($) operator in GHC 8.0 is problematic

> Christopher Allen : > > Sorry for the mostly off-topic post, but since a beginner’s Prelude was > > mentioned here multiple times recently as a countermeasure to making the > > real Prelude more complicated, I just want to say, don’t put too much hope > > into a ”solution”

Re: New type of ($) operator in GHC 8.0 is problematic

I agree 100% with Manuel here. My N is smaller (100s rather than thousands) but this is what I've seen working with self-learners, programmers and non-programmers alike. I don't have anything further to add because I couldn't find a point in his listing that didn't match my experience. > Sorry

Re: New type of ($) operator in GHC 8.0 is problematic

Hi Manuel, > * Introduce the concept of overloading right away. People get that easily, > because they use overloaded arithmetic functions in math, too. > (Num and Show are the typical classes to explain it at.) > As an example, see how we do that in the first chapter of our new Haskell >

Re: New type of ($) operator in GHC 8.0 is problematic

Hi Alexander, > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > For example: > foldr :: (a -> b -> b) -> b -> [a] -> b > foldr :: (a -> b -> b) -> b -> Maybe a -> b > foldr :: (a -> b -> b) -> b -> Identity a -> b > foldr :: (a -> b -> b) -> b -> (c, a) -> b > and more

Re: New type of ($) operator in GHC 8.0 is problematic

We have tried variations of this. This approach has two problems. (1) It’s generally easier to use something than to define it and, e.g., in the case of lists, Haskell ”magic” syntax is more intuitive to use. For example, we use lists for a while before we define them. Even recursive

Re: New type of ($) operator in GHC 8.0 is problematic

> Richard Eisenberg : > > On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote: >> Indeed. I'll just say that I envision that a beginner's prelude would be >> for learning and nothing more. The goal is that it would be used in the >> first dozen hours of

Re: New type of ($) operator in GHC 8.0 is problematic

On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote: > Indeed. I'll just say that I envision that a beginner's prelude would be > for learning and nothing more. The goal is that it would be used in the > first dozen hours of picking up the language and nothing more. > > I'd be

Re: New type of ($) operator in GHC 8.0 is problematic

Christopher Allen writes: > I don't think it's a good idea to create a dumbed down Prelude and existing > resources not covering what programmers need to know in order to actually > use Haskell as everyone else uses it is much of the reason I had to write a > book to begin

Re: New type of ($) operator in GHC 8.0 is problematic

"Boespflug, Mathieu" writes: >> As far as I know, there is currently know way to >> do this in 7.10. >> >> Given how much backlash there has been to changing the type of ($), ... > > Keep in mind... as we saw with FTP, that in this community it's often > unclear just how large or

Re: New type of ($) operator in GHC 8.0 is problematic

On Fri, Feb 5, 2016 at 2:16 PM, Takenobu Tani wrote: > Hi, > > I'll worry about the learning curve of beginners. > Maybe, beginners will try following session in their 1st week. > > ghci> :t foldr > ghci> :t ($) > > They'll get following result. > > > Before ghc7.8: >

Re: New type of ($) operator in GHC 8.0 is problematic

I don't think it's a good idea to create a dumbed down Prelude and existing resources not covering what programmers need to know in order to actually use Haskell as everyone else uses it is much of the reason I had to write a book to begin with. This type isn't just noise for beginners, it's noise

Re: New type of ($) operator in GHC 8.0 is problematic

Ah, and I offer my help in case development efforts is the main concern. Though I'm not familiar with this part of GHC, so I'd need a mentor. My help probably will not be very useful, but I'd be happy to participate. On Mon, 2016-02-15 at 15:21 +0300, Yuras Shumovich wrote: > On Mon, 2016-02-15

Re: New type of ($) operator in GHC 8.0 is problematic

On Mon, 2016-02-15 at 12:35 +0100, Herbert Valerio Riedel wrote: > On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote: > > [...] > > > > - It is possible to have unlifted types about even without > > > -XMagicHash. -XMagicHash is simply a lexer extension, nothing > > > more. > > > By

Re: New type of ($) operator in GHC 8.0 is problematic

> As far as I know, there is currently know way to > do this in 7.10. > > Given how much backlash there has been to changing the type of ($), ... Keep in mind... as we saw with FTP, that in this community it's often unclear just how large or tiny a group of people represent when they're vocal

Re: New type of ($) operator in GHC 8.0 is problematic

On 2016-02-15 at 12:00:23 +0100, Yuras Shumovich wrote: [...] >> - It is possible to have unlifted types about even without >> -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. >> By convention, we use the # suffix with unlifted things, but there's >> no requirement here.

Re: New type of ($) operator in GHC 8.0 is problematic

On Mon, 2016-02-15 at 14:00 +0300, Yuras Shumovich wrote: > Thank you for the reply! > > On Sun, 2016-02-14 at 22:58 -0500, Richard Eisenberg wrote: > > This approach wouldn't quite work. > > > > - It seems to kick in only when instantiating a Levity variable. > > That > > would not happen when

Re: New type of ($) operator in GHC 8.0 is problematic

Thank you for the reply! On Sun, 2016-02-14 at 22:58 -0500, Richard Eisenberg wrote: > This approach wouldn't quite work. > > - It seems to kick in only when instantiating a Levity variable. That > would not happen when using :info. Obviously Levity variables should be defaulted to Lifted

Re: New type of ($) operator in GHC 8.0 is problematic

"Boespflug, Mathieu" writes: > Hi Ben, > > thanks for the nice summary. I haven't been following all the details > in the meanderings of this thread, but perhaps someone can chime in > with an answer to this simple question: > > * has it been discussed what type ($) should have in

Re: New type of ($) operator in GHC 8.0 is problematic

Hi Ben, thanks for the nice summary. I haven't been following all the details in the meanderings of this thread, but perhaps someone can chime in with an answer to this simple question: * has it been discussed what type ($) should have in the Haddock's for base? If so, will it the one GHCi shows

Re: New type of ($) operator in GHC 8.0 is problematic

This approach wouldn't quite work. - It seems to kick in only when instantiating a Levity variable. That would not happen when using :info. - It is possible to have unlifted types about even without -XMagicHash. -XMagicHash is simply a lexer extension, nothing more. By convention, we use the

Re: New type of ($) operator in GHC 8.0 is problematic

Ryan Scott writes: > Hi Chris, > > The change to ($)'s type is indeed intentional. The short answer is > that ($)'s type prior to GHC 8.0 was lying a little bit. If you > defined something like this: > > unwrapInt :: Int -> Int# > unwrapInt (I# i) = i > ...

Re: New type of ($) operator in GHC 8.0 is problematic

On Sat, 2016-02-13 at 13:41 +0100, Ben Gamari wrote: > Ryan Scott writes: > > > Hi Chris, > > > > The change to ($)'s type is indeed intentional. The short answer is > > that ($)'s type prior to GHC 8.0 was lying a little bit. If you > > defined something like this: > >

Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

Hi Ben, Thank you for explanation. Sorry, I was misunderstood that ghc8 changes representation of '*'. (In addition to the Bool, but also Int, Float,..) There are also followings: Alternative f => Monoid (Alt (TYPE Lifted) f a) Functor (Proxy (TYPE Lifted)) Foldable (Const (TYPE Lifted)

Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

Takenobu Tani writes: > Hi, > > I understood one more point. (I share here.) > The Prelude library document for ghc 8.0 is already well described for > beginners/newcomers. > > * The ($)'s signature of 8.0.1 is already simple (not include forall ...). > * The Bool's kind

Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

Hi Richard and devs, What a wonderful (#11549) ! This is a beautiful solution for beginners/newcomers. Beginners will not confuse and they can gradually go ahead. I extremely appreciate that you are continuously improving the ghc for us. Thank you very much, Takenobu 2016-02-07 0:17 GMT+09:00

Re: New type of ($) operator in GHC 8.0 is problematic

On 05.02.2016 14:49, Richard Eisenberg wrote: - Edward is right in that (->) isn't really levity-polymorphic. Well, it is, but it's ad hoc polymorphism not parametric polymorphism. Perhaps in the future we'll make this more robust by actually using type-classes to control it, as we probably

Re: New type of ($) operator in GHC 8.0 is problematic

On 08.02.2016 16:36, Wojtek Narczyński wrote: On 05.02.2016 14:49, Richard Eisenberg wrote: - Edward is right in that (->) isn't really levity-polymorphic. Well, it is, but it's ad hoc polymorphism not parametric polymorphism. Perhaps in the future we'll make this more robust by actually

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

> Another great question that has come up is about Haddock output (Hackage). I > think Haddock needs to add a facility where library authors can include > specializations of an overly general type. This can be done in commentary, > but it's not as prominent. I think a low-hanging fruit would be

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

On 02/06/2016 03:55 PM, Roman Cheplyaka wrote: > But despite all the negativity in this thread, I want to say that your > work on this and other aspects of GHC is very much appreciated. Keep it up! > +1000 ___ ghc-devs mailing list

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

On Fri, Feb 5, 2016 at 6:21 PM, Mike Izbicki wrote: > > 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,

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a -fshow-runtime-rep flag (recalling that the name levity will soon be outdated) as described in this thread. I will make sure this gets in for the release of 8.0. Other points: - You're quite right that

Re: New type of ($) operator in GHC 8.0 is problematic

> On 06 Feb 2016, at 15:30, ghc-d...@stefan-klinger.de wrote: > > Richard, thank you very much for your elaborate statement. The > problem I see with a `BeginnersPrelude` is that it will either > outdate, or create a bubble escaping from which is so painful that > most new Haskell programmers

Re: New type of ($) operator in GHC 8.0 is problematic

That makes a lot of sense to me. Manuel > Roman Cheplyaka : > > On 02/05/2016 01:31 AM, Edward Z. Yang wrote: >> I'm not really sure how you would change the type of 'id' based on >> a language pragma. >> >> How do people feel about a cosmetic fix, where we introduce a new >>

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

On 02/06/2016 02:09 AM, Richard Eisenberg wrote: > The old type of ($) was always a lie. -XMagicHash just changes the > parser, allowing the # suffix. It is only by convention that most (all?) > unlifted things end in #. The old type of ($) was perhaps a harmless > lie, but a lie nonetheless. > >

Re: New type of ($) operator in GHC 8.0 is problematic

I have a side question and some possible alternate views on a couple things. The first is: is the fancy type of ($) actually used? It has additional special type checking behavior that isn't captured in that type (impredicative instantiation), but probably in a separate code path. Does that only

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

I just showed the type of ($) to my boss in our company chat who has been using Haskell for 14 years. He'd played with Haskell prior to that, but 14 years ago is when he started postgrad and teaching Haskell. Here's what he said: >...what? >what does that do? He's been using Haskell in

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

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

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

+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

Re: New type of ($) operator in GHC 8.0 is problematic

Hi, Am Freitag, den 05.02.2016, 09:22 +0200 schrieb Roman Cheplyaka: > On 02/05/2016 01:31 AM, Edward Z. Yang wrote: > > I'm not really sure how you would change the type of 'id' based on > > a language pragma. > > > > How do people feel about a cosmetic fix, where we introduce a new > > pragma,

Re: New type of ($) operator in GHC 8.0 is problematic

Hi, I'll worry about the learning curve of beginners. Maybe, beginners will try following session in their 1st week. ghci> :t foldr ghci> :t ($) They'll get following result. Before ghc7.8: Prelude> :t foldr foldr :: (a -> b -> b) -> b -> [a] -> b Prelude> :t ($) ($) :: (a -> b)

Re: New type of ($) operator in GHC 8.0 is problematic

As the instigator of these most recent changes: - Yes, absolutely, ($)'s type is quite ugly. In other areas, I've tried to hide the newfound complexity in the type system behind flags, but I missed this one. I consider the current output to be a bug. - It's conceivable to have a flag

Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

On 05/02/2016, Richard Eisenberg wrote: > -- click on the type The question so remains: what would we write to a purely textual terminal? ___ ghc-devs mailing list ghc-devs@haskell.org

Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

It may come as a surprise to many of you that I, too, am very worried about Haskell becoming inaccessible to newcomers. If we can't induct new people into our ranks, we will die. It is for this reason that I have always been unhappy with the FTP. But that ship has sailed. I fully agree with

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

Hi, I tried to draw informal illustrations about Foldable signatures for beginners [1]. I'll also try to draw simple illustrations about new ($). Of course I like Haskell's beautiful abstraction :) Thank you for your great efforts. [1]

Re: New type of ($) operator in GHC 8.0 is problematic

This seems worse than FTP IMO. It's considerably noisier, considerably rarer a concern for Haskell programmers, and is wa beyond the scope of most learning resources. Is there a reason this isn't behind a pragma? On Thu, Feb 4, 2016 at 5:02 PM, Manuel M T Chakravarty

Re: New type of ($) operator in GHC 8.0 is problematic

The sort of pragma you suggest would satisfy me. Pragmas like this don't bother me and make my job a fair bit easier. Too many, "don't worry about this; later" is exhausting. Too many, "don't worry about this; we're not even going to have time to cover it" is demoralizing. On Thu, Feb 4, 2016 at

Re: New type of ($) operator in GHC 8.0 is problematic

> make the kind of (->) more flexible. Can that wait until 8.2 so we don't have to edit the book as much in preparation for 8.0? :P On Thu, Feb 4, 2016 at 3:15 PM, Richard Eisenberg wrote: > I agree with everything that's been said in this thread, including the > unstated

Re: New type of ($) operator in GHC 8.0 is problematic

I'm not really sure how you would change the type of 'id' based on a language pragma. How do people feel about a cosmetic fix, where we introduce a new pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity arguments/TYPE. It's off by default but gets turned on by some

Re: New type of ($) operator in GHC 8.0 is problematic

To be honest, I think, it is quite problematic if an obscure and untested language extension (sorry, but that’s what it is right now) bleeds through into supposedly simple standard functionality. The beauty of most of GHC’s language extensions is that you can ignore them until you need them.

Re: New type of ($) operator in GHC 8.0 is problematic

I agree with everything that's been said in this thread, including the unstated "that type for ($) is sure ugly". Currently, saturated (a -> b) is like a language construct, and it has its own typing rule, independent of the type of the type constructor (->). But reading the comment that Ben

Re: New type of ($) operator in GHC 8.0 is problematic

On 02/05/2016 01:31 AM, Edward Z. Yang wrote: > I'm not really sure how you would change the type of 'id' based on > a language pragma. > > How do people feel about a cosmetic fix, where we introduce a new > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity >

Re: New type of ($) operator in GHC 8.0 is problematic

Hello, how about we simply use two operators: 1. ($) which only works for standard types (i.e., not #), which we can use 99% of the time, and 2. some other operator which has the levity polymorphic type and would be used in the advanced cases when you are working with unboxed values, etc.

Re: New type of ($) operator in GHC 8.0 is problematic

Hi Chris, The change to ($)'s type is indeed intentional. The short answer is that ($)'s type prior to GHC 8.0 was lying a little bit. If you defined something like this: unwrapInt :: Int -> Int# unwrapInt (I# i) = i You could write an expression like (unwrapInt $ 42), and it would

New type of ($) operator in GHC 8.0 is problematic

$ ghci :lGHCi, version 8.0.0.20160122: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/callen/.ghci Prelude> :t ($) ($) :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). (a -> b) -> a -> b As someone that's working on a book for beginners/intermediates and

Re: New type of ($) operator in GHC 8.0 is problematic

My understanding was that the implicitly polymorphic levity, did (->) not change because it's a type constructor? Prelude> :info (->) data (->) a b -- Defined in ‘GHC.Prim’ Prelude> :k (->) (->) :: * -> * -> * Basically I'm asking why ($) changed and (->) did not when (->) had similar properties

Re: New type of ($) operator in GHC 8.0 is problematic

> My understanding was that the implicitly polymorphic levity, did (->) not > change because it's a type constructor? The kind of (->) as GHCi reports it is technically correct. As a kind constructor, (->) has precisely the kind * -> * -> *. What's special about (->) is that when you have a

Re: New type of ($) operator in GHC 8.0 is problematic

Christopher Allen writes: > My understanding was that the implicitly polymorphic levity, did (->) not > change because it's a type constructor? > > Prelude> :info (->) > data (->) a b -- Defined in ‘GHC.Prim’ > Prelude> :k (->) > (->) :: * -> * -> * > > Basically I'm asking