- ghc-devs - Haskell.org

Merge FlexibleContexts with FlexibleInstances?
by David Feuer 06 Feb '15

06 Feb '15

In my limited experience thus far, it seems to me that a substantial majority of modules that start out needing one of these end up needing the other one too. They appear to be two sides of the same coin, each allowing for (slightly) more powerful termination checking. Should the two just be made synonyms, to cut down a tiny bit on the boilerplate LANGUAGE pragmas?

2 1

RE: [GHC] #10052: Panic (something to do with floatExpr?)
by Simon Peyton Jones 05 Feb '15

05 Feb '15

Peter: Here's a bad crash, due to you. (Doing this by email because I'm offline.) The (Tick t e) case of FloatOut.floatExpr is incomplete. It simply panics in some cases. Could you fix this please? Either that case shouldn't happen, in which case Core Lint should check for it, and whoever is generating it should be fixed. Or it should happen, in which case floatExpr should do the right thing. Could you leave a Note to explain what is happening in the floatExpr (Tick ...) cases? Thanks Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 31 January 2015 17:38 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #10052: Panic (something to do with floatExpr?) | | #10052: Panic (something to do with floatExpr?) | -------------------------------------+----------------------------------- | -- | Reporter: edsko | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.10.1-rc2 | Keywords: | Operating System: | Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | Blocking: | | Differential Revisions: | | -------------------------------------+----------------------------------- | -- | Loading | | {{{ | main = let (x :: String) = "hello" in putStrLn x | }}} | | using a very simple driver for the GHC API (see T145.hs) causes a ghc | panic: | | {{{ | [1 of 1] Compiling Main ( T145-input.hs, interpreted ) | T145: T145: panic! (the 'impossible' happened) | (GHC version 7.10.0.20150128 for x86_64-apple-darwin): | floatExpr tick | <<details unavailable>> | | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug | }}} | | This panic is arising in our test case for #8333, so it may be related | to | that bug. | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

2 4

Restricted Template Haskell
by Greg Weber 03 Feb '15

03 Feb '15

Hello GHC friends! I am starting up a proposal for variants of Template Haskell that restrict what operations are available. The goal is to make TH easier for users to reason about and to allow for an easier compilation story. Here is the proposal page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted Right now the proposal does not have any details and the goal is to write out a clear specification. If this sounds interesting to you, let me know or leave some feedback on the wiki. Thanks, Greg Weber

2 4

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

What is the story behind the type of undefined?
by David Feuer 01 Feb '15

01 Feb '15

If I define {-# LANGUAGE MagicHash #-} g :: Int# -> Int g 3# = 3 myUndefined = undefined then this gives a sensible type error about a kind mismatch: usual :: Int usual = g myUndefined but this, oddly enough, compiles: peculiar :: Int peculiar = g undefined GHCi and the definition in GHC.Error agree that undefined :: a So why am I allowed to use it as a type of kind #?

3 3

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