- ghc-tickets - Haskell.org

Re: [GHC] #7406: -ddump-ds does not turn on -fforce-recomp
by GHC 12 Jan '13

12 Jan '13

#7406: -ddump-ds does not turn on -fforce-recomp ----------------------------------------+----------------------------------- Reporter: goldfire | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Easy (less than 1 hour) | Testcase: Blockedby: | Blocking: Related: | ----------------------------------------+----------------------------------- Comment(by ian@…): commit 782faec0d6cd32bc922e3d489c2d44c9ca175a3e {{{ Author: Ian Lynagh <ian(a)well-typed.com> Date: Sat Jan 12 12:55:31 2013 +0000 Clarify docs on when -ddump-* imply -fforce-recomp; fixes #7406 docs/users_guide/flags.xml | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7406#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7563: Passing -C flag causes the 'impossible' to happen
by GHC 12 Jan '13

12 Jan '13

#7563: Passing -C flag causes the 'impossible' to happen ------------------------------------------------+--------------------------- Reporter: jstolarek | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Difficulty: Unknown Testcase: T7563 | Blockedby: Blocking: | Related: ------------------------------------------------+--------------------------- Changes (by igloo): * status: new => closed * testcase: => T7563 * resolution: => fixed Comment: Fixed, and test added. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7563#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7485: Tuple constraints not properly kinded
by GHC 12 Jan '13

12 Jan '13

#7485: Tuple constraints not properly kinded -------------------------------+-------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: ConstraintKinds Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by ekmett): * cc: ekmett@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7485#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7543: Constraint synonym instances
by GHC 12 Jan '13

12 Jan '13

#7543: Constraint synonym instances ---------------------------------+------------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by ekmett): * cc: ekmett@… (added) Comment: FWIW some form of fix for this would be quite useful to me as well. In the {{{lens}}} package we have a lot of classes that look like {{{ class Foo s t a b | s -> a, t -> b, s a -> t, t a -> s }}} where s = t, a = b are always legal to instantiate, so many instances look like {{{ class IsText Text Text Char Char }}} when we're dealing with these 4 parameter families for data types we adopt the convention that {{{ type Foo' a b = Foo a a b b }}} But we cannot do this for the declaration site for the instances. If we could this would (eventually, when we can remove support for pre- constraint kinds compilers) enable us to more easily expand our definitions later on. More pie-in-the-sky would be being able to use {{{ type Foo a b = Bar a => Baz a b }}} {{{ instance Foo a b }}} as {{{ instance Bar a => Baz a b }}} it would be consistent with the other uses of type, but {{{Bar a => Baz a b}}} doesn't (currently) have a sensible kind. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7543#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7554: Define __SSE__ when compiling with -msse
by GHC 11 Jan '13

11 Jan '13

#7554: Define __SSE__ when compiling with -msse -------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by tibbe): * status: patch => merge Comment: Merged as bab8dc7925a374ef91df3bca3d9a2aa9755212e1. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7554#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: Fundeps and type equality
by Richard Eisenberg 11 Jan '13

11 Jan '13

Yes, I finished and pushed in December. A description of the design and how to use the feature is here: http://hackage.haskell.org/trac/ghc/wiki/NewAxioms There's also a section (7.7.2.2 to be exact) in the manual, but building the manual from source is not for the faint of heart. Richard On Jan 10, 2013, at 3:14 PM, Carter Schonwald <carter.schonwald(a)gmail.com> wrote: > so the overlapping type families are in HEAD? > > Awesome! I look forward to finding some time to try them out :) > > > On Thu, Jan 10, 2013 at 1:56 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > For better or worse, the new overlapping type family instances use a different overlapping mechanism than functional dependencies do. Class instances that overlap are chosen among by order of specificity; overlapping instances can be declared in separate modules. Overlapping family instances must be given an explicit order, and those that overlap must all be in the same module. The decision to make these different was to avoid type soundness issues that would arise with overlapping type family instances declared in separate modules. (Ordering a set of family instance equations by specificity, on the other hand, could easily be done within GHC.) > > So, as yet, we can't fully encode functional dependencies with type families, I don't think. > > Richard > > On Jan 2, 2013, at 4:01 PM, Martin Sulzmann <martin.sulzmann.haskell(a)googlemail.com> wrote: > >> >> I agree with Iavor that it is fairly straight-forward to extend FC to support FD-style type improvement. In fact, I've formalized such a proof language in a PPDP'06 paper: >> "Extracting programs from type class proofs" >> (type improvement comes only at the end) >> >> Similar to FC, coercions (proof terms) are used to represent type equations (improvement). >> >> Why extend FC? >> Why not simply use type families to encode FDs (and thus keep FC simple and small). >> >> It's been a while, but as far as I remember, the encoding is only problematic in case of the combination of FDs and overlapping instances. Shouldn't this now be fixable given >> that type family instances can be overlapping? >> Maybe I'm missing something, guess it's also time to dig out some old notes ... >> >> -Martin >> >> On Wed, Jan 2, 2013 at 10:04 AM, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: >> As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). >> >> >> >> Iavor is quite right >> >> >> >> It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. >> >> >> >> Iavor: I don’t think it’s straightforward, but I’m willing to be educated. By all means start a wiki page to explain how, if you think it is. >> >> >> >> I do agree that injective type families would be a good thing, and would deal with the main reason that fundeps are sometimes better than type families. A good start would be to begin a wiki page to flesh out the design issues, perhaps linked from http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions >> >> >> >> The main issues are, I think: >> >> · How to express functional dependencies like “fixing the result type and the first argument will fix the second argument” >> >> · How to express that idea in the proof language >> >> >> >> Simon >> >> >> >> From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of Iavor Diatchki >> Sent: 26 December 2012 02:48 >> To: Conal Elliott >> Cc: glasgow-haskell-bugs(a)haskell.org; GHC Users Mailing List >> Subject: Re: Fundeps and type equality >> >> >> >> Hello Conal, >> >> >> >> GHC implementation of functional dependencies is incomplete: it will use functional dependencies during type inference (i.e., to determine the values of free type variables), but it will not use them in proofs, which is what is needed in examples like the one you posted. The reason some proving is needed is that the compiler needs to figure out that for each instantiation of the type `ta` and `tb` will be the same (which, of course, follows directly from the FD on the class). >> >> >> >> As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. >> >> >> >> In the mean time, the way forward would probably be to express the dependency using type families, which I find tends to be more verbose but, at present, is better supported in GHC. >> >> >> >> Cheers, >> >> -Iavor >> >> PS: cc-ing the GHC users' list, as there was some talk of closing the ghc-bugs list, but I am not sure if the transition happened yet. >> >> >> >> >> >> >> >> >> >> On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott <conal(a)conal.net> wrote: >> >> I ran into a simple falure with functional dependencies (in GHC 7.4.1): >> >> > class Foo a ta | a -> ta >> > >> > foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool >> > foo = (==) >> >> I expected that the `a -> ta` functional dependency would suffice to prove that `ta ~ tb`, but >> >> Pixie/Bug1.hs:9:7: >> Could not deduce (ta ~ tb) >> from the context (Foo a ta, Foo a tb, Eq ta) >> bound by the type signature for >> foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool >> at Pixie/Bug1.hs:9:1-10 >> `ta' is a rigid type variable bound by >> the type signature for >> foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool >> at Pixie/Bug1.hs:9:1 >> `tb' is a rigid type variable bound by >> the type signature for >> foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool >> at Pixie/Bug1.hs:9:1 >> Expected type: ta -> tb -> Bool >> Actual type: ta -> ta -> Bool >> In the expression: (==) >> In an equation for `foo': foo = (==) >> Failed, modules loaded: none. >> >> Any insights about what's going wrong here? >> >> -- Conal >> >> >> _______________________________________________ >> Glasgow-haskell-bugs mailing list >> Glasgow-haskell-bugs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs >> >> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

3 5

Re: [GHC] #7563: Passing -C flag causes the 'impossible' to happen
by GHC 11 Jan '13

11 Jan '13

#7563: Passing -C flag causes the 'impossible' to happen ---------------------------------+------------------------------------------ Reporter: jstolarek | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Driver | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by ian@…): commit 68833e5e8caa1c23f75ab8bea4377ede28ff9548 {{{ Author: Ian Lynagh <ian(a)well-typed.com> Date: Fri Jan 11 18:42:40 2013 +0000 Make "happensBefore" take account of whether we are unregisterised If we are not unregisterised then we skip the HCc phase. Fixes #7563. compiler/main/DriverPhases.hs | 61 +++++++++++++++++++++----------------- compiler/main/DriverPipeline.hs | 11 ++++--- 2 files changed, 40 insertions(+), 32 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7563#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7554: Define __SSE__ when compiling with -msse
by GHC 11 Jan '13

11 Jan '13

#7554: Define __SSE__ when compiling with -msse -------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by tibbe): * status: new => patch Comment: I managed to break my OS X install completely. Could someone else please merge? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7554#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 11 Jan '13

11 Jan '13

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+-------------------------------------------- Reporter: cetinsert | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Keywords: R_X86_64_PC32 | Os: Windows Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by bos): * cc: bos@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7134#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7097: linker fails to load package with binding to foreign library
by GHC 11 Jan '13

11 Jan '13

#7097: linker fails to load package with binding to foreign library ----------------------------------+----------------------------------------- Reporter: nus | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.2 Keywords: | Os: Windows Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: #2283 #3242 #1883 | ----------------------------------+----------------------------------------- Changes (by bos): * cc: bos@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7097#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0