- ghc-devs - Haskell.org

Re: [GHC] #7803: Superclass methods are left unspecialized
by Eric Crockett 06 Feb '16

06 Feb '16

https://ghc.haskell.org/trac/ghc/ticket/7803#comment:12 On Sat, Feb 6, 2016 at 11:14 AM, GHC <ghc-devs(a)haskell.org> wrote: > #7803: Superclass methods are left unspecialized > -------------------------------------+------------------------------------- > Reporter: akio | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.6.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Compile-time | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > I've started a pair of builds; I'll put up nofib results once they have > finished. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7803#comment:12> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 1

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Ben Gamari 06 Feb '16

06 Feb '16

Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> writes: > On Fri, Feb 05, 2016 at 07:19:25PM +0000, Tom Ellis wrote: >> On Fri, Feb 05, 2016 at 01:13:23PM -0500, Richard Eisenberg 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. >> >> Is there a list of situations where ($) is used currently that give rise to >> this need? > > Does anyone have any idea about this? What is it about ($) that means it > needs a new funky type whereas (apparently) nothing else does? The first (albeit rather unconvincing) example I can think of is be something like, getI# :: Int -> Int# getI# (I# n#) = n# n# :: Int# n# = getI# $ 5 + 8 Richard likely has something a bit less contrived though. This does raise the question of why ($) is generalized, yet (.) is not, (.) :: forall (l :: Levity) a b (c :: TYPE l). (b -> c) -> (a -> b) -> (a -> c) (.) f g x = f (g x) Cheers, - Ben

1 0

Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
by Richard Eisenberg 06 Feb '16

06 Feb '16

A bit of time away from my keyboard has revealed a natural way to solve this problem and others: be more like Idris. Normally, of course, I'm thinking about how Haskell's type system can be more like Idris's. But that's not what I mean here. I want Haskell's interface to be more like Idris's. Imagine this interchange: λ> :t ($) ($) :: (a -> b) -> a -> b -- click on the type ($) :: forall a b. (a -> b) -> a -> b -- click on the a ($) :: forall (a :: *) b. (a -> b) -> a -> b -- click on the b ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b -- where b's kind has a different color than usual -- click on b's kind ($) :: forall {r :: RuntimeRep} (a :: *) (b :: TYPE r). (a -> b) -> a -> b -- mouseover RuntimeRep or TYPE reveals a tooltip "($) is representation-polymorphic, meaning that `b` can have an arbitrary runtime representation. Please see http://.... for more details." Similarly, classes would render in a special color, allowing you to click on them and choose to instantiate the type at a few in-scope instances of the class at hand, changing Foldable f => f a -> Int to the much simpler [a] -> Int. This is not a minor engineering project, but it would reap wonderful rewards, addressing the problems in this thread and more. No more lying (because all lies are clickable), no more fragmented language, no more brakes on development. Evidently, Chris already agrees with this proposal: #10073 (https://ghc.haskell.org/trac/ghc/ticket/10073) Also see #8809 (https://ghc.haskell.org/trac/ghc/ticket/8809) Any volunteers to implement this? :) Richard On Feb 5, 2016, at 7:47 PM, Artyom <yom(a)artyom.me> wrote: > I’ve amended my suggestion to say basically “this type is a slight lie, here’s a flag/command to see the true type” – this way we aren’t scaring people with implementation guts, merely letting them see the guts for themselves and then think “I don’t care about this” (which is, I think, exactly what should happen; the worst scenario here is that the beginner falls into the “I’m an advanced user, I need all features, I need to know everything, so I’ll enable the flag” trap – which is why it’s important not to call it “an advanced type” or mention “if you know what you’re doing” or anything else like that). > > I don’t agree that levity can be compared to Java’s “class” or “static” – not because it’s harder to understand, but because it’s much less widely used; I don’t feel that you need to know about levity in order to be a good Haskeller. Also, unboxed types don’t imply knowledge of levity – for instance, I’ve been successfully using unboxed types for a while, but I only found out about the true type of ($) by complete accident (I think I queried the kind of -> and then got curious about question marks). Of > > On 02/06/2016 03:27 AM, Mihai Maruseac wrote: > > > >> On Fri, Feb 5, 2016 at 7:09 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >>> 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. Such a new feature would address the ($) problem, >>> as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a specialization >>> of its real type. It would also help a great deal with FTP-related >>> generalizations. >> This goes hand in hand with Artyom's suggestion of a warning in GHCi >> after showing the simpler type. >> >> I'm thinking of a flag which enables/disables printing the simplest >> type with warning (in GHCi) or footnote (or otherwise, in Haddock). We >> can have the default behavior of the flag be either printing the >> simpler type + extra (warning/footnote) or printing the longer type >> and include a reference in our learning materials that beginners and >> people confused by the long, complex and real type, can use >> --use-simpler-types flag. >> > >

2 1

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Christopher Allen 05 Feb '16

05 Feb '16

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 production for the last 5 years as well, I think. Please simplify the type unless a pragma specific to levity is turned on. As it happens, I like the name levity better than runtimerep, but neither solve any pedagogical issues. YMMV. On Fri, Feb 5, 2016 at 1:12 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > On 02/05/2016 08:05 PM, Christopher Allen 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. > > > > I think you're being a bit harsh, but I *do* think you're essentially > right. Beginners will have no idea what most the that means, so... *yes* > the type *will* need to be simplified for display purposes. (Unless, of > course, you opt-in to full signatures.) > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Allen Currently working on http://haskellbook.com

1 0

Guarantees for ST and IO shared in common?
by Christopher Allen 04 Feb '16

04 Feb '16

Underlying ST is: GHC.Prim.State# s -> (# GHC.Prim.State# s, a #) Underlying IO is: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, a #) Based on the (very helpful!) conversation I had on the #ghc IRC channel, it seems to me that the mechanism for preventing things like reordering operations or spurious sharing is shared in common between ST and IO via State#. Is this accurate? I believe the exception is how RealWorld is used w/ IO but we can put that off for this question. If anyone could confirm this understanding that would be helpful. If anyone could point out exceptions to this notion, I'd very much appreciate that as well. Thanks again for everyone's time. -- Chris Allen Currently working on http://haskellbook.com

2 2

New type of ($) operator in GHC 8.0 is problematic
by Christopher Allen 04 Feb '16

04 Feb '16

$ 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 that mentions ($) early'ish, this is pretty disconcerting. Particularly as we're not going to explain Levity or TYPE. Is this intentional? My only ~/.ghci flag is fno-warn-type-defaults. Apologies if this is a mix-up on my part. --- Chris

1 0

Re: Automatically deriving Generic for every algebraic data type
by Ryan Scott 04 Feb '16

04 Feb '16

I'm a pretty solid -1 on this idea. On a general level, I'm opposed to the idea of deriving typeclasses without the programmer opting in. Most typeclasses express operations that your datatype must support, and in the case of Generic(1), it mandates that users can convert between values of your datatype and an isomorphic representation type. As Oleg noted, this completely destroys encapsulation for datatypes whose constructors you don't want to export. Another issue is the nontrivial cost of automatic derivation. Typeclasses can be surprisingly expensive to derive. About a year ago, Reid Barton measured the amount of increase in code size that each derivable typeclass contributes [1], and Generic was far and away the most expensive one. There's also the issue that deriving Generic on large datatypes can drastically increase the amount of memory needed during compilation [2]. Yet another problem is that deriving Generic1 simply doesn't work for every datatype. Not only does deriving Generic1 not work with sophisticated language features (e.g., -XExistentialQuantification [3]) by design, but there are still a number of outstanding bugs that prevent legitimate Generic1 from being deriving automatically. For example, the following datatype: newtype Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) chokes when attempting to derive Generic1 automatically [4]. You have to hack around this by using -XStandaloneDeriving with a programmer-specified instance context. One could imagine a compromise in which Generic(1) would not be derived for datatypes for which attempting to derive those classes yields an error. But I would argue that this is very undesirable, since programmers would just expect every datatype to work out of the box with Generic(1), only to find "Cannot find instance Generic1 Compose"-like errors when they try using Generic1 operations on datatypes that trip the bug mentioned in [4]. There are exceptions to the don't-derive-typeclasses-automatically rule, with Typeable being a notable example [5]. But deriving Typeable has the benefit that (1) it doesn't impose many requirements on your datatype (other than you can get a TypeRep for it), (2) it's cheap to derive (see the table in [1]), and (3) it works on literally every datatype. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/9557#comment:8 [2] https://ghc.haskell.org/trac/ghc/ticket/5642 [3] https://ghc.haskell.org/trac/ghc/ticket/10514 [4] https://ghc.haskell.org/trac/ghc/ticket/10524#comment:16 [5] https://ghc.haskell.org/trac/ghc/ticket/8950

2 1

Automatically deriving Generic for every algebraic data type
by Wolfgang Jeltsch 04 Feb '16

04 Feb '16

Hi, if you do generic programming these days, you can use DeriveAnyClass to write code like the following (where Serializable is a class with a generic default implementation): > data Tree a = Leaf | Branch (Tree a) a (Tree a) > deriving (Generic, Serializable) It would be great, if you could just write the following instead: > data Tree a = Leaf | Branch (Tree a) a (Tree a) deriving Serializable This would correspond exactly to what you do when using standard Haskell deriving. It could be made possible by letting the compiler instantiate the Generic class automatically every time an algebraic data type is declared. A potential downside of this would be that programmers would not be able to define non-standard instances of Generics, but I actually cannot see that this is very useful anyhow. Any comments? All the best, Wolfgang

3 3

Specializing expressions beyond names?
by Conal Elliott 04 Feb '16

04 Feb '16

It seems to be the case that SPECIALIZE pragmas are syntactically restricted to type specializations of a *name* (identifier) rather than a general expression. Is my understanding correct here? If so, is there any reason for this restriction? I ask because I’m reifying Core code (into code that constructs a corresponding run-time representation for further processing), and I’m looking for a clean way to integrate that process with GHC, to support separate compilation and to avoid interfering with GHC’s regular flow. It occurred to me that I could enable separate compilation via a pragma of the form “{-# SPECIALIZE reify foo ∷ E t #-}” for some t, where E t is a reified form of values of type t. Type checking would infer the specialized type of foo, and the usual specialization phase would do its usual thing on that specialization, leaving “reify foo = reify specialized_foo”, and then the reification compiler plugin would transform the right-hand side, pushing the reify inward. Some reify calls may remain (e.g., due to polymorphism), triggering future rule applications. As much as possible of the fully-reified version would be factored out of the generated rule’s RHS for cheap reuse. Thanks, - Conal

2 3

CallStack naming
by Richard Eisenberg 03 Feb '16

03 Feb '16

Hi devs, I'm sure there's an easy answer to this, but I'm wondering: why is the CallStack feature implemented with implicit parameters instead of just a magical constraint? Whenever I use this feature, I don't want to have to enable -XImplicitParams and then make sure I get the name right. What would be wrong with, e.g., > undefined :: AppendsCallStack => a Seems simpler. Is it problems with a nullary class? Thanks, Richard

6 18