February 2016 - ghc-devs

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

PrimRep constructor Vec
by Richard Eisenberg 03 Feb '16

03 Feb '16

Hi Geoff, I'm working on the fix for #11471, which involves interacting with the PrimRep type. (You don't need the ticket background to understand this question, though.) One of PrimRep's constructors is VecRep, which Simon tells me is your domain. The problem is that I can find nowhere in the source code where this constructor is used. I see several consumers, but no producers. Is this constructor now unused? Should I remove it? Thanks, Richard

3 3

Re: Adding a "release" setting in build.mk.sample (and some other build system questions)
by Harry . 03 Feb '16

03 Feb '16

> https://ghc.haskell.org/trac/ghc/wiki/MakingReleases#Makingthebinarybuilds > https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration So the mysterious SRC_HC_OPTS = -O -H64m which appears in every build flavour isn't used for the release build?

3 3

Re: [GHC] #11526: unsafeLookupStaticPtr should not live in IO
by Mathieu Boespflug 02 Feb '16

02 Feb '16

IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will never change, and an aux table populated as new objects get linked in. Then programs can "opt in" to taking into account new objects loaded dynamically by reading (in IO) the aux table. Sent from my mobile. I'll have a look at the new material on the wiki shortly. It would be nice to close out the basic distributed story.

2 1