- ghc-devs - Haskell.org

Adding rules in a plugin?
by Conal Elliott 11 Feb '16

11 Feb '16

I'm writing a GHC plugin that generates new rules. The top-level identifier for the new rules' LHSs is always the same and is imported from another module. One of the arguments in the rule's LHSs, however, is defined in that module. I'm creating rules and adding them to the mg_rules of the module's ModGuts. I don't see them in the .hi files (viewed with "ghc --show-iface Foo.hi"), and they're not getting found in modules that import the modules where I'm trying to generate rules. Am I missing a crucial step? For instance, do I need also to use `addIdSpecialisations` with the argument identifiers, and if so, need I replace all instances of those identifiers in the module or just some of them? Thanks, -- Conal

2 2

Making a core app with a function having context in core2core plugin?
by Magesh B 11 Feb '16

11 Feb '16

Hi GHC Devs, Is it possible to make a core app with a function having contexts? For example, let us take showable :: P.Show a => a -> String showable = P.show Say, I would like to app showable with (Just 'a') in the core, which requires the following code showable @ (Maybe Char) *($fShowMaybe @ Char $fShowChar)* (Just @ Char (C# 'a')) But I couldn't find a way to construct the dictionary required by showable function myself in the core. Is there any ghc api using which I can get the required dictionary for a particular type (in the above case, Dictionary for Show instance of Maybe Char). Regards, Magesh B

1 0

problem compiling GHC 8.0.1 release candidate 2 src on Apple
by George Colpitts 07 Feb '16

07 Feb '16

"/usr/local/bin/ghc" -M -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -this-unit-id terminfo-0.4.0.2 -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist-boot/build/autogen/cabal_macros.h -package-id base-4.9.0.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -fno-warn-unused-imports -fno-warn-deprecated-flags -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist-boot/build -stubdir libraries/terminfo/dist-boot/build -dep-makefile libraries/terminfo/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps libraries/terminfo/./System/Console/Terminfo.hs libraries/terminfo/./System/Console/Terminfo/Base.hs libraries/terminfo/./System/Console/Terminfo/Cursor.hs libraries/terminfo/./System/Console/Terminfo/Color.hs libraries/terminfo/./System/Console/Terminfo/Edit.hs libraries/terminfo/./System/Console/Terminfo/Effects.hs libraries/terminfo/./System/Console/Terminfo/Keys.hs ghc: unrecognised flag: -this-unit-id Usage: For basic information, try the `--help' option. make[1]: *** [libraries/terminfo/dist-boot/build/.depend-v.haskell] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/local/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/local/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","8.0.0.20160111") ,("Project Git commit id","497454fc6610d67a2b2cd7902390c6497bddb483") ,("Booter version","7.10.2") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-8.0.0.20160111") ,("Global Package DB","/usr/local/lib/ghc-8.0.0.20160111/package.conf.d") ] On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari <ben(a)well-typed.com> wrote: > > Hello everyone, > > The GHC Team is very pleased to announce the second release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Source and binary > distributions as well as the newly revised users guide and Haddock > documentation can be found at > > http://downloads.haskell.org/~ghc/8.0.1-rc2/ > > This is the second in a series of release candidates leading up to the > 8.0.1 > release and fixes many of the issues reported in -rc1. These fixes > include, > > * A re-rewrite of the pattern checker by George Karachalias. The new > checker should have far more predictable performance characteristics > while sacrificing minimal reasoning power. This should resolve a > large number of the issues felt in -rc1. > > * Richard Eisenberg has been hammering out all manner of > type-application- and TypeInType-related issues (#11335, #11416, > #11405). There is still more work to do here, however (e.g. #11471). > > * Matthew Pickering has restored support for multi-clause pattern > synonyms (#11367) > > * A latent bug in the constraint solver which popped up as a build > failure in xmonad-contrib in -rc1 has been fixed (#11379) > > * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a > variety of older type-checker bugs at a furious rate (#11458, > #11248, #11330, #11408) > > * Simon Peyton Jones has taught demand analysis to more precisely > handle exceptions (#11222) > > * Tamar Christina has added support for remote GHCi on Windows > and resolved a long-standing linking issue (#11223) > > * Loading of compiled modules needing shared library symbols now works > in GHCi thanks to Peter Trommler (#10458) > > * A variety of limitations in our implementation of Typeable > implementation have been fixed (#11120) although there is still more > to be done (#11334). > > * A terrible failure of type inference due to visible type application > has > been fixed (#11458) > > * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies > > * Custom type errors are now more robust (#11391) although there is > still more work to be done (#11541) > > * We now have a more conservative default warning set, as well as > better mechanisms for managing warning changes in the future. > (#11429, #11370) > > * Compatibility with earlier Cabal versions should be a bit more > robust. > > * The user-facing interface of the (formerly "implicit") CallStack > functionality has been reworked, hiding the implicit callstack > parameter behind a constraint synonym. > > * Online haddock documentation has been restored (#11419) > > * We now offer xz archives exclusively > > * A variety of miscellaneous bug-fixes have also been merged. > > All of these changes add up to nearly 200 commits in total. Given the > large amount of churn between this candidate and -rc1, as well as the > fact that there is at least one more significant patch pending (D1891, > to fix #11471 and others), we will be releasing a third release > candidate in a few weeks which should address more of the issues listed > on the release status page [1]. Assuming things go well, we should be > able to cut a final release by early March at the latest. > > All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit > e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the > Windows builds*. Unfortunately, it was realized only too late that the > tagged commit is broken on Windows. Consequently, the Windows builds > were produced from the ghc-8.0.1-rc2 tag with two additional patches > (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of > course be completely unacceptable for a proper release, time constraints > have meant that this was unfortunately the only viable option for this > release candidate. We apologize for any confusion this may cause. > > At this point we are working very hard to nail the remaining bugs > labelled as "highest" priority on the 8.0.1 status page [1]. If you have > an issue which you'd like to see addressed in the release that does not > appear in this list, please bring it to our attention. > > As always, we look forward to hearing about any issues that you > encounter with this candidate. Thanks to everyone who has contributed so > far! > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >

2 1

StgCase - are LiveVars and SRT fields going to be used?
by Ömer Sinan Ağacan 06 Feb '16

06 Feb '16

Hi all, This is how case expression in STG currently defined: | StgCase (GenStgExpr bndr occ) (GenStgLiveVars occ) (GenStgLiveVars occ) bndr SRT AltType [GenStgAlt bndr occ] The GenStgLiveVars and SRT fields are never used anywhere in the compiler (except the printer). So the question is, I'm assuming those were used at some point, but are they going to be used in the future? Or can I just delete those? As a proof of concept, I just compiled GHC using this: | StgCase (GenStgExpr bndr occ) bndr AltType [GenStgAlt bndr occ] Normally this is not a big deal, but I'm doing lots of STG-to-STG transformations nowadays, and I have to keep those field updated which is annoying as those are never going to be used (I can't even know if I'm doing it right), or leave those `undefined` which is not a good practice.

2 4

Re: New type of ($) operator in GHC 8.0 is problematic
by ghc-devs＠stefan-klinger.de 06 Feb '16

06 Feb '16

Hi there, I'm teaching Haskell to 2nd semester computer science students, and I have been teaching Haskell since 2006. While I certainly do appreciate the constant developement of Haskell, and GHC, I'm becoming more and more concerned about the learning curve involved. For our students it is an entirely new concept that “Application” can be an operator. They are just learning about associativity. `foldl` and `foldr` are *baffling* concepts to them. They have never thought of functions being values. They have never looked at a strict type system. Having `Foldable` pop up last year already was not optimal, and to be honest, this ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b is a disaster for teaching — Sorry. 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 will hesitate to take the step. GHC developement will carry on, more and more things being hidden behind `BeginnersPrelude` automatically. We will end up educating Beginners that will want to stay beginners. I'd personally wish for a `-fdefault-levity` switch, but I do not oversee all the consequences right now. I know it puts load on you, but this actually just tells you that the language you're building became a bit less learnable, maybe it's good to be aware of that. Kind regards Stefan -- http://stefan-klinger.de o/X Send plain text messages only, not exceeding 32kB. /\/ \

2 1

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