January 2015 - ghc-devs

GHC support for the new "record" package
by Simon Marlow 02 Feb '15

02 Feb '15

For those who haven't seen this, Nikita Volkov proposed a new approach to anonymous records, which can be found in the "record" package on Hackage: http://hackage.haskell.org/package/record It had a *lot* of attention on Reddit: http://nikita-volkov.github.io/record/ Now, the solution is very nice and lightweight, but because it is implemented outside GHC it relies on quasi-quotation (amazing that it can be done at all!). It has some limitations because it needs to parse Haskell syntax, and Haskell is big. So we could make this a lot smoother, both for the implementation and the user, by directly supporting anonymous record syntax in GHC. Obviously we'd have to move the library code into base too. This message is by way of kicking off the discussion, since nobody else seems to have done so yet. Can we agree that this is the right thing and should be directly supported by GHC? At this point we'd be aiming for 7.12. Who is interested in working on this? Nikita? There are various design decisions to think about. For example, when the quasi-quote brackets are removed, the syntax will conflict with the existing record syntax. The syntax ends up being similar to Simon's 2003 proposal http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html (there are major differences though, notably the use of lenses for selection and update). I created a template wiki page: https://ghc.haskell.org/trac/ghc/wiki/Records/Volkov Cheers, Simon

18 67

Re: Restricted Template Haskell
by Greg Weber 31 Jan '15

31 Jan '15

On Fri, Jan 30, 2015 at 7:05 PM, adam vogt <vogt.adam(a)gmail.com> wrote: > Hi Greg, > > Perhaps a less-invasive way to implement the -XSafe part of your > proposal would be to provide a module like: > > module Language.Haskell.TH.Safe ( > module Language.Haskell.TH, > reifyWithoutNameG, > ) where > import Language.Haskell.TH hiding (runIO, reify*) > > where reifyWithoutNameG is the same as reify, except definitions that > are out of scope are either missing or modified such that they use > NameQ instead of NameG for out-of-scope names. > Thanks, I added this concept to the wiki. > That way there is no new syntax needed, and safe TH can be called by > unsafe TH without any conversions. > > I think defining another monad like Q that can do less is too > inconvenient because you have to disambiguate between Safe.listE and > Unsafe.listE, or make those functions more polymorphic (which makes > type errors worse). Another option would be if there were > Oh, you are getting into more concrete details now than I have even thought about! For the restricted monad route, we might look into a more capable method of using capabilities that would end up looking like this: reify :: Name -> Restrict (TH :+: Reify) Info runIO :: IO a -> Restrict (TH :+: RunIO) a There are still a lot of details to work out, thanks for getting things started.

1 0

7.10.1RC2 compile problem? ghc: internal error: PAP object entered!
by George Colpitts 31 Jan '15

31 Jan '15

Maybe this is something I shouldn't be doing, but I thought it was worth mentioning in case I have found a compiler bug. Should I file a bug for this? cabal install *--allow-newer=base* accelerate ... [10 of 10] Compiling Data.Label.Base ( src/Data/Label/Base.hs, dist/build/Data/Label/Base.o ) ghc: internal error: PAP object entered! (GHC version 7.10.0.20150123 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

4 5

Delaying 7.10?
by Simon Peyton Jones 31 Jan '15

31 Jan '15

Friends In a call with a bunch of type hackers, we were discussing https://ghc.haskell.org/trac/ghc/ticket/9858 This is a pretty serious bug. It allows a malicious person to construct his own unsafeCoerce, and so completely subverts Safe Haskell. Actually there are two bugs (see comment:19). The first is easily fixed. But the second is not. We explored various quick fixes, but the real solution is not far out of reach. It amounts to this: * Every data type is automatically in Typeable. No need to say "deriving(Typeable)" or "AutoDeriveTypeable" (which would become deprecated) * In implementation terms, the constraint solver treats Typeable specially, much as it already treats Coercible specially. It's not a huge job. It'd probably take a couple of days of implementation work, and some time for shaking out bugs and consequential changes. The biggest thing might be simply working out implementation design choices. (For example, there is a modest code-size cost to making everything Typeable, esp because that includes the data constructors of the type (which can be used in types, with DataKinds). Does that matter? Should we provide a way to suppress it? If so, we'd also need a way to express whether or not the Typable instance exists in the interface file.) But it is a substantial change that will touch a lot of lines of code. Moreover, someone has to do it, and Iavor (who heroically volunteered) happens to be travelling next week. So it's really not the kind of thing we would usually do after RC2. But (a) it's serious and, as it happens, (b) there is also the BBP Prelude debate going on. Hence the question: should we simply delay 7.10 by, say, a month? After all, the timetable is up to us. Doing so might give a bit more breathing space to the BBP debate, which might allow time for reflection and/or implementation of modest features to help the transition. (I know that several are under discussion.) Plus, anyone waiting for 7.10 can simply use RC2, which is pretty good. Would that be a relief to the BBP debate? Or any other opinions. Simon PS: I know, I know: there is endless pressure to delay releases to get stuff in. If we give in to that pressure, we never make a release. But we should know when to break our own rules. Perhaps this is such an occasion.

11 12

integer-gmp-1.0.0.0 ?
by Richard Eisenberg 31 Jan '15

31 Jan '15

Hi devs, I've just hit on a strange bug, and I don't know where to start looking. In my branch where I'm building support for dependent types (github.com/goldfirere/ghc.git; branch: nokinds.... but you don't need to look there) I'm going through the testsuite and picking off bugs one at a time. I'm very puzzled by the output I'm getting from typecheck/should_compile/tc231, which does a -ddump-tc. At the end, I see ... Dependent modules: [] Dependent packages: [base-4.8.0.0, ghc-prim-0.3.1.0, integer-gmp-1.0.0.0] Notice the version number of integer-gmp. I haven't touched anything near there! And, my integer-gmp.cabal file says 0.5.1.0, which is what I'd expect. Sure enough, when I use the inplace `ghc-pkg list`, I see that I have integer-gmp-1.0.0.0 installed, along with all the other boot packages with their correct version numbers. Any hints here? I can surely work around this, but it's very strange! Thanks! Richard

2 1

A straw-man compatibility proposal
by Howard B. Golden 30 Jan '15

30 Jan '15

(This is intended to be a serious, though partially-complete, proposal. I offer it in the hope it starts a constructive discussion.) The rapid changes in GHC have both good and bad aspects. I am specifically discussing proposals which break existing code. My goal is to offer ground rules to make changes easier to implement by easing the pain they cause to current programmers, their existing code and language learners. _DESIRABLE_ FEATURES OF GHC CHANGES: 1. Breaking existing code should be avoided UNLESS a simple method is provided to continue to compile the old code for a reasonable transition period. 1a. Corollary: When changes are made to the Prelude, provision should be made to allow the older Prelude(s) for a reasonable transition period, so existing code can be used during a reasonable transition period. 1b. Corollary: Since GHC changes (especially to the Prelude) will require changes in commonly used libraries, which will take time to complete and stabilize, the transition period should be long enough to incorporate this as well as changes to programs using these libraries. 1c. Corollary: A suitable subset of code on Hackage should compile either under the changed feature or (by a simple method) the prior feature for a reasonable transition period. Any failure of this subset to compile should be an absolute stop to releasing a new version of GHC. 1d. Corollary: Haskell 98 and Haskell 2010 standard-conforming code should compile either under the changed feature or (by a simple method) the prior feature for a reasonable transition period. Any failure of standard-conforming code to compile should be an absolute stop to releasing a new version of GHC. (Reason: Currently available books and other teaching material still generally are written to conform to Haskell 98. It is desirable to allow language learners to compile code included in their existing learning materials to reduce their learning curve.) 2. One method of satisfying (1) is to include compiler flag(s) to select various versions of Haskell Preludes and commonly used libraries compatible with those Preludes. Alternatively, other simple methods are acceptable. 3. It is desirable to provide automated tools that will update existing code to the newer Prelude and libraries. The existence of such tools will influence the length of the transition period. DISCUSSION 1. Adoption of Haskell is retarded by difficulty learning the language, which is increased if learning materials don't compile. 2. Adoption of Haskell for production use is retarded by GHC changes that break existing code, necessitating ongoing maintenance. This can be ameliorated by automated tools to update existing code. 3. If GHC developers and library maintainers consider the impact of their changes and seek to minimize their immediate and longer-term impact, this will enable greater adoption of Haskell which will expand the Haskell community to everyone's benefit.

1 0

Make one-shot a per-registration property
by Kazu Yamamoto 30 Jan '15

30 Jan '15

Hi, This is just confirmation. Ben's one-shot patch (*1) is included in master but not included in the ghc-7.10 branch. Is this intentional? Is it supposed to be merged in GHC 7.12? (*1) 023439980f6ef6ec051f676279ed2be5f031efe6 https://phabricator.haskell.org/D347 --Kazu

4 4

the performance of IO manager in GHC 7.10.1rc2
by Kazu Yamamoto 29 Jan '15

29 Jan '15

Hi, As usual, I took benchmark of IO manager to check if preformance regression is introduced. Fortunately, I don't see any preformance regression. +RTS -N<x> 1 2 4 8 16 --------------------------------------------------------- GHC7.8.4 81,413 153,478 270,178 406,448 50,3203 GHC7.10.1rc2 88,247 148,471 265,392 409,514 49,3890 Environment: two real 20 cores machines directly connected by 20G - Xeon E5-2650Lv2 (1.70GHz/10cores/25MB) x 2, 8GM, no HT - CentOS 7.0 - Two 10Gs are aggregated Server: witty -a -m -r 8080 +RTS -A32m -N<x> Benchmark: weighttp -n 100000 -c 1000 -k -t 16 http://<ip-addr>/ P.S. If Ben's patch will be included in GHC 7.10, I will try this again. --Kazu

2 2

A simpler ORF
by Iavor Diatchki 29 Jan '15

29 Jan '15

Hello, I've been following the various discussions about changes to Haskell's record system, and I find that most of the current proposals are fairly complex, especially for the benefit they provide. I use Haskell records a lot, and I've been wondering if there might be a simpler alternative, one that: 1. will allow us to reuse field names across records 2. does not require any fancy types 3. it will not preclude continued research on "the right" way to get more type-based record resolution. Based on designs I've seen in the past, my experience with Haskell records, and discussions with colleagues, I put together a document describing a potential design that, I think, satisfies goals 1 to 3: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Simple I think the proposal should be fairly simple to implement, and I'd be willing to do it, if there is enough support from the community. Let me know what you think! -Iavor

5 5

Put "Error:" before error output
by Konstantine Rybnikov 28 Jan '15

28 Jan '15

Hi! I'm bringing this up once again. Can we add "Error:" in the output of an error in a similar way ghc shows "Warning:" for warnings? Main reasoning is that, for example, on a build-server, where you have lots of cores to build your program, if you get an error, it gets lost somewhere in the middle of compiler's output in all other "Warning" messages you get, since error is not always shown last on multi-core build. Thanks.

7 12