RE: Fundeps and type equality
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-boun...@haskell.org [mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Iavor Diatchki Sent: 26 December 2012 02:48 To: Conal Elliott Cc: glasgow-haskell-bugs@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 co...@conal.netmailto:co...@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@haskell.orgmailto:Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: DoCon and GHC
Serge
That's odd. I've tried with both 7.6 and HEAD, and both fail on T_cubeext thus:
T_cubeext.hs:102:10:
Overlapping instances for LinSolvRing (UPol k)
arising from a use of `upEucRing'
Matching instances:
instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a)
-- Defined in `docon-2.12:Pol2_'
instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) =
LinSolvRing (UPol (Pol a))
-- Defined in `docon-2.12:Pol3_'
(The choice depends on the instantiation of `k'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
In the expression: upEucRing unA Map.empty
In an equation for `dA': dA = upEucRing unA Map.empty
I am using ghc-7.6 from Dec 3 (ie *later* than the released GHC 7.6.1), so
perhaps the difference in error message is due to a bug in 7.6.1 that's fixed
in my version. I suggest you use the 7.6.2 release candidate.
Anyway, the error message looks entirely legitimate. It really does matter how
'k' is instantiated! I have no idea how it compiled before.
The solution is to add (EuclideanRing k) to the type sig of cubicExt. Then it
compiles all the way up to the top.
Simon
| -Original Message-
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-
| bugs-boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 21 December 2012 18:46
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: DoCon and GHC
|
| On Fri, Dec 21, 2012 at 01:45:04PM +, Simon Peyton-Jones wrote:
| OK, do this
|
| * {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}
|
| * import Categs( Domains1 )
|
| * Add type sig for dP'
| dP' :: (LinSolvRing (Pol a), CommutativeRing a) = Domains1 (Pol
| a)
|
| Then it compiles.
|
| You are very close to the edge of what can be done!
|
|
| It works. Thank you.
|
| There remains only a single unlucky module: T_cubeext.
| The test demotest/Main works with exception of T_cubeext, but I need
| T_cubeext.cubicExt to work.
|
| Please, continue the test with
|
| make install
| cd demotest
| ghc $doconCpOpt --make Main
|
| (for $doconCpOpt =
| -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports
| -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns
| -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances
| -XTypeSynonymInstances -XFlexibleInstances -XOverlappingInstances ).
|
| It reports
|
| --
| ...
| T_cubeext.hs:102:20:
| Could not deduce (k ~ k1)
| from the context (Field k, FactorizationRing (UPol k))
| bound by the type signature for
| cubicExt :: (Field k, FactorizationRing (UPol k)) =
| k - k - Domains1 k - (Domains1 (E k), [E
| k], k - E k)
| at T_cubeext.hs:(79,13)-(80,69)
| or from (Field k1, FactorizationRing (UPol k1))
| bound by the type signature for
| unA :: (Field k1, FactorizationRing (UPol k1)) = UPol
| k1
| at T_cubeext.hs:101:9-56
| `k' is a rigid type variable bound by
| the type signature for
| cubicExt :: (Field k, FactorizationRing (UPol k)) =
| k - k - Domains1 k - (Domains1 (E k), [E k],
| k - E k)
| at T_cubeext.hs:79:13
| `k1' is a rigid type variable bound by
|the type signature for
| unA :: (Field k1, FactorizationRing (UPol k1)) = UPol k1
|at T_cubeext.hs:101:9
| Expected type: Domains1 k1
| Actual type: Domains1 k
| In the second argument of `cToUPol', namely `dK'
| In the expression: cToUPol d dK unK
| In an equation for `unA': unA = cToUPol d dK unK
|
| T_cubeext.hs:105:7:
| Overlapping instances for LinSolvRing (UPol k1)
| arising from a use of `upEucRing'
| Matching instances:
| instance [overlap ok] EuclideanRing a = LinSolvRing (UPol a)
| -- Defined in `docon-2.12:Pol2_'
| instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) =
| LinSolvRing (UPol (Pol a)) ...
| --
|
| I tried {-# LANGUAGE ScopedTypeVariables, MonoLocalBinds #-}, and
| setting type signatures in various parts in cubicExt.
| But this does not help.
|
| There is another point. In
| ``cubicExt :: (Field k, FactorizationRing (UPol k)) = ...''
|
| the part ``, FactorizationRing (UPol k)'' (1)
|
| was always considered as parasitic. ghc-7.4.1 needs (1) to work, and
| at least ghc-7.4.1 does compile the test.
|
| I thought, may be, the future compilers will allow to omit this part.
| At least it is desirable for ghc-7.6.2 to do the test in any variant,
| with (1) or without it.
|
| Regards,
|
| --
| Sergei
RE: DoCon and GHC
I would not use -XMonoLocalBinds for all modules -- that will force you to do
more work.
Instead use it just for the offending Pol3_ module, via {-# LANGUAGE
MonoLocalBinds #-}
Or, probably better, give a type signature inside moduloBasisx, as suggested in
the http://hackage.haskell.org/trac/ghc/ticket/4361. The signature is better
because it also makes the program easier to understand!
Simon
| -Original Message-
| From: Serge D. Mechveliani [mailto:mech...@botik.ru]
| Sent: 21 December 2012 10:08
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: DoCon and GHC
|
| On Wed, Jun 20, 2012 at 04:56:01PM +, Simon Peyton-Jones wrote:
| Serge
|
| I hope you are well.
|
| I'm making a significant simplification to the type inference engine,
| which will have a small knock-on effect in DoCon.
|
| I implemented a VERY DELICATE HACK to solve your problem before, but
| it has become a significant problem to maintain the hack, so I'm
| taking it out.
|
| See http://hackage.haskell.org/trac/ghc/ticket/4361, and the comments
| I have added there, which tell you what change to make. It's very
| minor!
|
| This will take effect from GHC 7.6 onwards. Thanks
|
| Simon
|
|
| This is on Ticket #4361 (closed bug: fixed)
| about compiling DoCon.
|
| Its story is as follows.
|
| * 7.4.0 failed to compile the module Pol3_ in DoCon due to
| 1) a certain GHC manner of constraint simplification (as Simon
| wrote)
| 2) a due to complex enough constraints used in DoCon, in particular,
| instance (LinSolvRing (Pol a), CommutativeRing a) =
| LinSolvRing (UPol (Pol a))
| set in Pol3_.hs
| (I do not know how to simplify this constraint without loosing
| generality).
|
| * 7.4.1 does compile it, but, as Simon wrote, applies for this a very
| specific and unstable compilation method.
| * 7.6+ removes this latter method, and Simon P. Jones concludes
|
| Happily, it's extremely easy to fix your source code in either of
| these two ways:
|
| * If you use -XMonoLocalBinds (which is in any case implied by -XGADTs
|and -XTypeFamilies), then GHC won't generalise the definition of x
| in the example, and all will be well.
|
| * Alterantively, give a type signature for x, thus (in this case)
|
|moduloBasisx p = let x :: ()
| x = upLinSolvRing p
| in ()
|
|
|
| Now, I am trying ghc-7.6.1.20121207 built from source on Debian Linux.
|
|
| I. I try adding -XMonoLocalBinds for compiling DoCon:
|
|
| -- doco.cabal --- ...
| ghc-options:
| -fno-warn-overlapping-patterns -fwarn-unused-binds
| -fwarn-unused-matches -fwarn-unused-imports -XMonoLocalBinds
| -O
| --
|
| `make build' fails at the first module:
|
| --
| module Prelude_
| where
| ...
| instance (DShow a, DShow b) = DShow (a, b)
| ...
| where
| dShows opts (x, y) = showChar '(' . shows1 x . showString sep .
| shows1 y . showChar ')' --
| line 628
| where
| opts'= addToShowOptions (- 1) $ opts {parInShow = Parens}
| sep = fieldSeparator opts
| shows1 x = (case parInShow opts of Parens - id
|_ - unparensUpper ())
|. dShows opts' x
|
| aShows (a, b) = showString (pair . aShows a . showChar ' ' .
|aShows b . showChar ')'
| --
|
| The report is
|
| runghc Setup.hs build
| Building docon-2.12...
| Preprocessing library docon-2.12...
| [ 1 of 84] Compiling Prelude_ ( Prelude_.hs,
| dist/build/Prelude_.o )
|
| Prelude_.hs:628:32:
| Could not deduce (a ~ b)
| from the context (DShow a, DShow b)
| bound by the instance declaration at Prelude_.hs:622:10-43
| `a' is a rigid type variable bound by
| the instance declaration at Prelude_.hs:622:10
| `b' is a rigid type variable bound by
| the instance declaration at Prelude_.hs:622:10
| In the first argument of `shows1', namely `y'
| In the first argument of `(.)', namely `shows1 y'
| In the second argument of `(.)', namely shows1 y . showChar ')'
| ...
| ---
|
| The line 628 is marked in the code as -- line 628.
|
|
| I suspect that besides -XMonoLocalBinds, I need also to add some
| explicit type signatures, for example,
| dShows opts (x, y) = showChar '(' . shows1 (x :: DShow a = a) .
|...
|
| Because GHC, probably, finds some contradiction in applying shows1 to
| x :: a and to y :: b.
|
|
| II. My another attempt will be removing -XMonoLocalBinds
| (with this, it compiles many modules and stops at Pol3.hs
RE: DoCon and GHC
| It looks like http://hackage.haskell.org | | is not valid now. Is this due to the recently announced e-mail lists | reorganization? It's working fine for me. No reorganisation there. Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #5910: Holes with other constraints
Replying by email because I'm on a train.
Dear xnyhps
Hmm. My intent was to allow typechecking to continue when there are holes (so
compiling them, similar to {{{undefined}}}, to something like {{{throw#}}}).
If I understand your suggestion correctly, we should abort compilation and
show the hole's type as errors when an unresolved hole is found.
No, not at all. Your new stuff will integrate beautifully with
-fdefer-type-errors. With this flag, TcErrors will build an error thunk for
any unsolved constraints, thereby deferring the error until runtime just as you
wanted. So you can use the holes as to-dos. Look at
TcErrors.reportTidyWanteds, and note the call to deferToRuntime.
If you want to defer only *holes*, but not other type errors, until runtime,
you'd need another flag, but I think as a first cut deferring *all* type errors
(including holes) would do. Or alternatively you could by-default defer holes
but not other errors. But then you'd still want a flag to say don't defer
holes.
I strongly urge you to use the TcErrors stuff. It does precisely what you
want. If you don't see how, ask more.
Simon
| -Original Message-
| From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-
| boun...@haskell.org] On Behalf Of GHC
| Sent: 05 March 2012 14:19
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: [GHC] #5910: Holes with other constraints
|
| #5910: Holes with other constraints
| +---
| Reporter: xnyhps | Owner:
| Type: feature request | Status: new
| Priority: normal | Milestone:
| Component: Compiler (Type checker) | Version: 7.5
| Keywords: holes| Os: Unknown/Multiple
| Architecture: Unknown/Multiple | Failure: Incorrect warning at
compile-
| time
|Difficulty: Unknown |Testcase:
| Blockedby: |Blocking:
| Related: |
| +---
|
| Comment(by xnyhps):
|
| Replying to [comment:2 simonpj]:
|Some brief responses. We may want a Skype chat.
|
| * I think the Right Way to do this is to add a new form of constraint,
| as you have done.
|
| * I do not see why you need `tcl_holes` in the `TcLclEnv`.
|
| Sorry, this was a relic from an earlier attempt. I thought I still needed
| it, but I don't. I'll update the patch (I want to make sure it can build
| stage1 as well).
|
|
| * The place to report the unsolved holes is '''not''' in `TcRnDriver`,
| but rather in `TcErrors`. It is a thing of beauty. The constraint solver
| tries to solve the constraints, ''returning an unsolved constraint''. The
| latter is passed to `reportUnsolved` and '''that''' is the place to report
| any unsolved holes.
|
|
| The `TcRnDriver` stuff is definitely a placeholder, most of the stuff
| there should actually be a part of GHCi instead.
|
| * Moreover, `TcErrors` ''already has'' a kind of error prioritisation:
| it does not report ambiguity errors if it any more important errors (such
| as holes) happen first: see `tryReporters` in `reportInsolsAndFlats`. So
| that will deal nicely with the problem you describe.
|
|
| Hmm. My intent was to allow typechecking to continue when there are holes
| (so compiling them, similar to {{{undefined}}}, to something like
| {{{throw#}}}). If I understand your suggestion correctly, we should abort
| compilation and show the hole's type as errors when an unresolved hole is
| found.
|
| But maybe what I want it unfeasible to do correctly with classes. I
| suppose that to compile {{{show _h}}} (where {{{_h}}} is a hole) the
| compiler wants to have a concrete function to use as the show, but the
| {{{Show}}} constraint is still ambiguous due to it being on a hole
| therefore it can't find any instance to use.
|
| It seems useful to me to be able to test different parts of your code when
| you put in a hole. I see the holes as TODOs in the code, for parts you
| need to finish later while you work on other stuff first (though maybe it
| could be combined with the deferring of type errors to runtime? Haven't
| experimented with that myself, I just noticed it in the code).
|
| * Finally, here's a fresh idea. If you store the `TcTypeEnv` in the
| `CtOrigin` of the hole, then when you report the hole as an error you can
| look at the type environment (better zonk it first) and print the types of
| all locally bound identifiers. Or some. Or whatever.
|
|
| That sounds like a very interesting idea, I will definitely look more at
| this later. Thanks!
|
| --
|
RE: Template Haskell and tuple sections
It's like any other TH feature. Template Haskell has a data type of its own to represent Haskell. This lags GHC-Haskell. All that's needed is to *Design changes to the TH type (in Language.Haskell.TH.Syntax), and establish that everyone is happy with them *Change the to- and fro- convertors to understand them (DsMeta and Convert). This particular one is relatively simple, because it concerns expressions (rather declarations). So, more power to you. Simon From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 23 January 2012 23:47 To: glasgow-haskell-bugs@haskell.org Subject: Template Haskell and tuple sections I just bumped into this limitation: runQ [| (,2) |] interactive:1:9: Tuple sections not (yet) handled by Template Haskell (, 2) which I see is the case at least through GHC 7.2.2. I'd love to see this limitation removed. Is this difficult? -- Conal ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #5539: GHC panic - Simplifier ticks exhausted
Ian, Could you look at the reported simplifier-ticks-exhausted bugs, and increase the multiplier in SimplMonad line 93 until they are all ok. Then assign the tickets to me (perhaps link them), because I want to see why they are high. Maybe there is something interesting going on. Thanks Simon | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of GHC | Sent: 15 December 2011 12:01 | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted | | #5539: GHC panic - Simplifier ticks exhausted | -+-- | Reporter: hvr | Owner: simonpj | Type: bug | Status: new | Priority: normal | Milestone: 7.4.1 | Component: Compiler|Version: 7.3 | Resolution: | Keywords: | Os: Linux | Architecture: x86_64 (amd64) |Failure: Compile-time crash | Difficulty: | Testcase: | Blockedby: | Blocking: |Related: | -+-- | | Comment(by tibbe): | | Could we please bump the priority of this ticket? Large swats of packages | don't build due to vector not building. | | -- | Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5539#comment:18 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #5051: Typechecker behaviour change
I believe that's right. Simon | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 23 June 2011 11:03 | To: glasgow-haskell-bugs@haskell.org | Cc: glasgow-haskell-us...@haskell.org | Subject: Re: [GHC] #5051: Typechecker behaviour change | | Simon, | thank you. | | Currently, DoCon works under ghc-7.0.1. | And as I understand, the next release which is going to support DoCon | (with its heavy use of overlapping instances) will be ghc-7.2. | | Regards, | | Serge Mechveliani, mech...@botik.ru | | | On Wed, Jun 22, 2011 at 11:01:53AM -, GHC wrote: | #5051: Typechecker behaviour change | ---+ |Reporter: igloo | Owner: simonpj |Type: bug | Status: closed |Priority: high | Milestone: 7.2.1 | Component: Compiler |Version: 7.0.2 | Resolution: fixed | Keywords: | | [..] | | GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather | subtle interaction of overlapping instances with the ill-fated silent | superclass parameters I introduced to solve a problem in the | typechecker's constraint solver. | [..] | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Add/Change #3557 (SIMD operations in GHC.Prim)
No, I don't think its subsumed by DPH at all. I'm ignorant of the details, but my sense is: go for it! Simon From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Alexander McPhail Sent: 26 October 2010 10:01 To: r...@cse.unsw.edu.au; glasgow-haskell-bugs@haskell.org Subject: Add/Change #3557 (SIMD operations in GHC.Prim) Hi, Does DPH resolve this issue or are SIMD primitives an orthogonal issue? I might take a look at this ticket if it is still relevant. Cheers, Vivian DISCLAIMER This transmission contains information that may be confidential. It is intended for the named addressee only. Unless you are the named addressee you may not copy or use it or disclose it to anyone else. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: report on 7.01-pre
Serge Thanks very much for the bug report. I've fixed it, so do try again with the next release candidate. Thanks Simon | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 30 September 2010 16:34 | To: glasgow-haskell-bugs@haskell.org | Cc: glasgow-haskell-us...@haskell.org | Subject: report on 7.01-pre | | Dear GHC developers, | | http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc701preBug.zip | | contains a bug report on ghc-7.0.0.20100924 | tested on Debian Linux, i386-family. | | Its essence is as follows. At the fragment of | | - | instance (LinSolvRing (Pol a), CommutativeRing a) = -- (1) |LinSolvRing (UPol (Pol a)) | where | gxBasis [] = ([], []) | gxBasis fs@(f:_) = | let | UPol _ p y dP= f | (o, n) = (pPPO p, genericLength $ pVars p) | (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) | p' = toLex p | dP' = upLinSolvRing p' Map.empty | s' = cToUPol y dP' p' | ... | - | | in the module Pol3_.hs, ghc-7.0.0.20100924 reports that | the line of `s' =' needs (EuclideanRing a) and that it cannot deduce | it. | | ghc-6.12.2 compiles this in a correct way: | (EuclideanRing a) is not necessary here, while the context (1) is more | generic and sufficient. | For example, for a = DirectSum Integer Integer, | `a' has the instances (1) and has not the instance of Euclidean, and | the above code must work. | This is the idea of the author of the application; | this idea is supported by ghc-6.12.2 and not supported by | ghc-7.0.0.20100924. | | There are the two questions. | 1) Whether this intention with instances is correct in the meaning of |Haskell + ghcExt |(I hope, it is correct, at least, ghc-6.12.2 accepts it). | 2) If it is correct, why ghc-7.0.0.20100924 requires (Euclidean a) ? | | Notices | --- | a) This application uses multiparametric classes and overlapping |instances (see docon.cabal for language and other options). | b) The example code can be reduced further, many times. |But I may have time to reduce it maybe only in the middle of |December 2010. | | Regards, | | - | Serge Mechveliani | mech...@botik.ru | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #4201: Improve eta reduction
Yes I'll do taht | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of GHC | Sent: 04 August 2010 17:37 | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #4201: Improve eta reduction | | #4201: Improve eta reduction | -+-- | Reporter: simonpj |Owner: simonpj | Type: bug | Status: patch | Priority: high |Milestone: 6.14.1 |Component: Compiler | Version: 6.12.3 | Keywords:| Testcase: |Blockedby:| Difficulty: | Os: Unknown/Multiple | Blocking: | Architecture: Unknown/Multiple | Failure: None/Unknown | -+-- | Changes (by igloo): | | * owner: = simonpj | | | Comment: | | Simon, probably best if you take a look at this patch? | | -- | Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4201#comment:5 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #2798: Enable rec keyword when RecursiveDo is enabled?
| I hope that it does but I have not installed GHC 6.12 yet. I was | wondering more how to write new programs that are not restricted to | work only with GHC = 6.12.1. Sometimes one can make things portable | with a bit of CPP---not pretty but it works---but, in this case, I | could not think of a good way to do this, so if anyone has ideas... Yes you can. Since nothing except 6.12 has 'rec', you can use 'mdo'. If you don't want the deprecation warning use -fno-warn-deprecations. Of course *any* feature removal is going to lead to programs that used to work not working any more. I don't see how to avoid that, except by keeping all features forever. We can keep mdo as long as necessary, I suppose, but I'd like some mechanism to gently encourage people to the rec syntax, which is what the deprecation warning should do. Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #3714: Improve error message if an associated family declaration has excess parameters
Indeed. But do you want to use that syntax for class parameters too? That
would be a big change
class C {|a|} where
S
| -Original Message-
| From: Stefan Holdermans [mailto:ste...@cs.uu.nl]
| Sent: 09 December 2009 08:42
| To: glasgow-haskell-bugs@haskell.org
| Cc: Simon Peyton-Jones
| Subject: Re: [GHC] #3714: Improve error message if an associated family
| declaration has excess parameters
|
| Simon,
|
| Regarding distinguishing between type indices and parameters, you
| suggested:
|
| type family T3 f !e :: * -- The ! indicates a type parameter
| (not
| an index)
|
| I'd rather have indices, rather than parameters, explicated by mean of
| syntax. This seems more consistent with ordinary type declarations.
|
| On paper, I often find myself writing
|
|type family T3 {|f|} e :: * .
|
| (A remnant of overexposure to generic programming, I guess.)
|
| Cheers,
|
|Stefan
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Associated data types + GADTs: known bug?
Conal It compiles OK in the HEAD, and therefore I expect 6.12. So that's good In general associated types and GADTs should work just fine together. In practice, I'm amazed they work as well as they do, because the current infrastructure is creaking. I'm working with Tom and Dimitrios on a new type-constraint-solving engine, which should be much more robust and predictable. Simon From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 05 December 2009 06:48 To: glasgow-haskell-bugs@haskell.org Subject: Associated data types + GADTs: known bug? Combining associated data types + GADTs proves fatal to GHCi 6.10.3 and 6.10.4. Is this bug known? If so, is it fixed in a later ghc? There's a stand-alone example at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13629 - Conal ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC Bug report
Two things to say.
First, you've said INLINE for both functions. GHC understands that as saying
replace a call to this function by the RHS that I'm writing right here. So
GHC doesn't optimise them much, if at all. It waits until it sees a call, then
inlines, then optimises *that*. So try calling 'firstnonspace' and see what
you get.
The only bad thing is that if you write (map firstnonspace xs), then there's no
visible call to firstnonspace, so the non-optimised version will get executed.
I'm in the middle of fixing that, with an upheaval of the way inlining works.
Simon
From: glasgow-haskell-bugs-boun...@haskell.org
[mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Jason Dagit
Sent: 02 October 2009 00:01
To: glasgow-haskell-bugs@haskell.org
Cc: Simon Marlow; Ian Lynagh
Subject: Fwd: GHC Bug report
[I just found out that there is a dedicated bugs email address so forwarding
the original message there.]
Hello,
I've created a small example of the program I have at this URL with the output
of -ddump-simpl:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10109#a10109
Notice that on line 139, I would like it if the Word8 could be passed without
boxing.
The full program text is here also in case the link above disappears:
\begin{code}
{-# LANGUAGE BangPatterns, MagicHash #-}
module Main where
import GHC.Word ( Word8(W8#) )
import GHC.Exts ( Int#, Int(I#), Ptr(..), Word#, Word(W#) )
import GHC.Prim ( indexWord8OffAddr#, (==#), (=#), (+#), word2Int#, Addr# )
isSpaceWord8 :: Word8 - Bool
isSpaceWord8 !w =
w == 0x20 ||-- ' '
w == 0x09 ||-- '\t'
w == 0x0A ||-- '\n'
w == 0x0D -- '\r'
{-# INLINE isSpaceWord8 #-}
firstnonspace :: Ptr Word8 - Int - Int - Int
firstnonspace (Ptr p) (I# n) (I# m) = I# (first p n m)
where
first :: Addr# - Int# - Int# - Int#
first addr n' m'
| n' =# m' = n'
| otherwise = if (not (isSpaceWord8 ch))
then n'
else first addr (n' +# 1#) m'
where
ch = W8# (indexWord8OffAddr# addr n')
{-# INLINE firstnonspace #-}
main = return ()
\end{code}
The output from ghc -O2 -ddump-simpl is:
\begin{core}
Tidy Core
Main.a :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.a =
\ (s_aHK :: GHC.Prim.State# GHC.Prim.RealWorld) -
(# s_aHK, GHC.Unit.() #)
Main.a1 :: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GlobalId]
[Arity 1
Str: DmdType L]
Main.a1 =
GHC.TopHandler.a5
@ ()
(Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IOhttp://GHC.IOBase.IO ()))
Main.main :: GHC.IOBase.IOhttp://GHC.IOBase.IO ()
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType L]
Main.main =
Main.a
`cast` (sym ((GHC.IOBase.:CoIO) ())
:: GHC.Prim.State# GHC.Prim.RealWorld
- (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
~
GHC.IOBase.IOhttp://GHC.IOBase.IO ())
Main.lit :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit = GHC.Word.W8# __word 13
Main.lit1 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit1 = GHC.Word.W8# __word 10
Main.lit2 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit2 = GHC.Word.W8# __word 9
Main.lit3 :: GHC.Word.Word8
[GlobalId]
[NoCafRefs
Str: DmdType m]
Main.lit3 = GHC.Word.W8# __word 32
Main.isSpaceWord8 :: GHC.Word.Word8 - GHC.Bool.Bool
[GlobalId]
[Arity 1
NoCafRefs
Str: DmdType U(L)]
Main.isSpaceWord8 =
__inline_me (\ (w_ap1 :: GHC.Word.Word8) -
GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit3)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit2)
(GHC.Classes.||
(GHC.Word.==2 w_ap1 Main.lit1) (GHC.Word.==2 w_ap1
Main.lit
Main.firstnonspace :: GHC.Ptr.Ptr GHC.Word.Word8
- GHC.Types.Inthttp://GHC.Types.Int
- GHC.Types.Inthttp://GHC.Types.Int
- GHC.Types.Inthttp://GHC.Types.Int
[GlobalId]
[Arity 3
NoCafRefs
Str: DmdType U(L)U(L)U(L)m]
Main.firstnonspace =
__inline_me (\ (ds_dGa :: GHC.Ptr.Ptr GHC.Word.Word8)
(ds1_dGb :: GHC.Types.Inthttp://GHC.Types.Int)
(ds2_dGc :: GHC.Types.Inthttp://GHC.Types.Int) -
case ds_dGa of wild_B1 { GHC.Ptr.Ptr p_ap6 -
case ds1_dGb of wild1_XB { GHC.Types.I# n_ap8 -
case ds2_dGc of wild2_XG { GHC.Types.I# m_apa -
letrec {
first_sH5 :: GHC.Prim.Addr#
- GHC.Prim.Int#http://GHC.Prim.Int
- GHC.Prim.Int#http://GHC.Prim.Int
RE: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Since this is a tricky bug, would it be worth having a Trac ticket for it, and capturing the state of play thereon? S | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Simon Marlow | Sent: 27 April 2009 12:59 | To: Sigbjorn Finne | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..? | | On 24/04/2009 23:04, Sigbjorn Finne wrote: | I've been experiencing repeated woes over the past 4-5 months | when trying to spin up build trees on Windows with the new build | system. This is happening on the 3-4 boxes that I regularly develop on, | which leads me to believe that this may not be limited to just me.. | | The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when | compiled and linked via the 'ghc' that's configured against, will produce | .exe's that crashes right out of the gates. gdb'ing the generated binaries, | the crash is happening in the CRT startup code with some further poking | around I've been able to determine that it is the explicit presence of -l | options for 'kernel32' and 'msvcrt' when linking that's the cause. This is | with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). | Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is | well-behaved, but ghc is still using gcc-3.4.5. | | We have seen this problem here on Satnam Singh's machine, but we | eventually put it down to a conflict between versions of certain MSYS | bits. There may indeed be a real problem here, I don't know. | | On Satnam's machine we established that the problem was provoked by | updating binutils, and the solution was don't do that (Satnam had | originally done this because the windres that comes with MSYS was | incompatible with GHC, but that can be worked around by just copying in | a suitable windres). | | We also tracked it down as far as compiling a trivial C program with | -lmsvcrt. | | Incedentally if you follow the instructions on the wiki exactly, you | won't run into this problem: | http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. | | There's a couple of things that are odd here: | | * base.cabal files have kernel32 and msvcrt as extra-libraries. This is | clearly | not required when doing invocations via ld(1), and causes considerable | mischief, | so it'd be good if there was a way in .cabal files to distinguish | between stuff that | goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's | InstalledPackageInfos. (Is there? Couldn't locate anything appropriate | while | working with the Cabal sources..) | | * 'base' needing to include these two dependencies even for GHCi usage. A | running RTS will have these loaded already, so it really ought to have | primed | the list of opened DLLs by explicitly loading them upon initialization | of the linker. | [I've got a trivial patch against rts/Linker.c that does this; can | forward/commit if | of interest..] | | I've no idea why these library dependencies are there. It might well be | historical. I'm happy to defer to Windows experts such as yourself on | whether we should have them or not (I guess not?). | | * In addition to the patch referred to above, to solve these problems, I | had to scrub | libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the | package.conf's for the | versions of ghc I'm building against had to be edited, limiting the use | of 'kernel32' | and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' | packages. | | Long and rambling..hope you made it this far ;-) Is anyone else running | into this issue | should we do something about it? If not, details of compilation | environment that | you've got that avoids running into this issue would be most welcome. | It's a bit of a | chore spinning up new builds, as is. | | One open question is whether we should expect gcc foo.c -lmsvcrt to | work. It works with older versions of MSYS/mingw, but apparently not | with more recent versions. On the face of it this seems like it ought | to be harmless, since msvcrt will eventually be linked in anyway. | | Cheers, | Simon | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid]
It's a bit unusual, but it shows up in a situation like this
data T a where
T1 :: T Int
T2 :: T Bool
x :: T Char
...case x of { ... }
In this case no patterns can match, so the entire case should be unreachable.
In this situation the entire case is replaced by (error Impossible
alternative). (Should really say Unreachable case expression.)
It's quite difficult to make this happen without the enclosing code also being
unreachable and discarded, which is why I flagged it. You could do some
-dverbose-core2core stuff to see it happening if you liked, but no, it should
not be harmful.
Simon
From: glasgow-haskell-bugs-boun...@haskell.org
[mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Conal Elliott
Sent: 04 March 2009 19:55
To: glasgow-haskell-bugs@haskell.org
Subject: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid]
I'm getting this message from ghc 6.11.20090115:
mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid]
My code compiles and seems to run okay. Is it anything to worry about?
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: seg-fault in 6.10.1
Yes we are. If you aren't using the FFI or unsafe things, you should not get a seg fault. Do help us to reproduce it -- thanks. Simon | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 23 January 2009 13:59 | To: glasgow-haskell-bugs@haskell.org | Cc: glasgow-haskell-us...@haskell.org | Subject: seg-fault in 6.10.1 | | Dear GHC team, | | I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, | run the executable, and obtain | | Segmentation fault. | | Then, I noted that in a few places the compiler warned about skipping | some class member implementations in some instances. | I added these implementations, and now it works correct. | | Are you interested in the bug report on the above part of | Segmentation fault ? | | - | Serge Mechveliani | mech...@botik.ru | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -XDisambiguateRecordFields
It's a documentation bug -- sorry. I'll fix that. The flag is -XDisambiguateRecordFields Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani | Sent: 20 November 2008 09:06 | To: glasgow-haskell-bugs@haskell.org | Subject: -XDisambiguateRecordFields | | The ghc-6.10.1 doc writes about -fdisambiguate-record-fields, | the compiler does not recognize it, | also it does not recognize -XDisambiguate-record-fields, | and it does recognize -XDisambiguateRecordFields. | | Also is not it better to uniformly use an upper case letter instead of | dash everywhere in flags? | | Regards, | | - | Serge Mechveliani | [EMAIL PROTECTED] | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: TypeCompose Patch
I believe it's fixed in HEAD and 6.10; I recall Manuel saying he'd done it, the same day I told him. (I thought I'd created a Trac ticket for it, but I don't seem to have done so.) (Worth noting for future: if you create a ticket you can follow the history more easily.) As to the my linear map implementation, but not when it tickles a ghc bug for me and for readers, do we have a Trac ticket for that? I don't know what the bug is, nor whether it's fixed. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott Sent: 12 October 2008 06:36 To: Simon Peyton-Jones Cc: glasgow-haskell-bugs@haskell.org Subject: Re: TypeCompose Patch What's the status of this bug? I'd like to know when it's safe to upgrade to a new ghc. Also, I want to blog about my linear map implementation, but not when it tickles a ghc bug for me and for readers. Thanks, - Conal 2008/9/25 Simon Peyton-Jones [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Conal, Marc This is definitely a bug in the new equality-solving mechanism. I can reproduce it readily. I'll discuss it with Manuel tomorrow and get back to you. Thanks for finding it! Simon | -Original Message- | From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:glasgow-haskell-bugs-mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Marc Weber | Sent: 25 September 2008 01:50 | To: glasgow-haskell-bugs@haskell.orgmailto:glasgow-haskell-bugs@haskell.org | Subject: Re: TypeCompose Patch | | On Wed, Sep 24, 2008 at 02:55:01PM -0700, Conal Elliott wrote: | Eep! That code (which uses type classes) fails to compile under 6.8.3 | but | does compile under 6.9. Looks like 6.10 broke something. | | Can anyone else check whether vector-space build or breaks under 6.10? | The repo is | | [1]http://code.haskell.org/vector-space/ | | src/Data/LinearMap.hs|37 col 21 error| | || Couldn't match expected type `t' against inferred type `Basis u' | || In the second argument of `(.)', namely `basisValue' | || In the first argument of `trie', namely `(f . basisValue)' | || In the expression: trie (f . basisValue) | | Hi Conal, I'm getting the error above (current ghc from darcs) | If you want I can give you an ssh account where this ghc version is | installed within the next days. | | I also had to add a -fglasgow-exts to a MemoTrie file.. | (Not sure which is the correct language extension which was missing) | | Sincerly | Marc Weber | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.orgmailto:Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.orgmailto:Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: TypeCompose Patch
Conal, Marc This is definitely a bug in the new equality-solving mechanism. I can reproduce it readily. I'll discuss it with Manuel tomorrow and get back to you. Thanks for finding it! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Marc Weber | Sent: 25 September 2008 01:50 | To: glasgow-haskell-bugs@haskell.org | Subject: Re: TypeCompose Patch | | On Wed, Sep 24, 2008 at 02:55:01PM -0700, Conal Elliott wrote: | Eep! That code (which uses type classes) fails to compile under 6.8.3 | but | does compile under 6.9. Looks like 6.10 broke something. | | Can anyone else check whether vector-space build or breaks under 6.10? | The repo is | | [1]http://code.haskell.org/vector-space/ | | src/Data/LinearMap.hs|37 col 21 error| | || Couldn't match expected type `t' against inferred type `Basis u' | || In the second argument of `(.)', namely `basisValue' | || In the first argument of `trie', namely `(f . basisValue)' | || In the expression: trie (f . basisValue) | | Hi Conal, I'm getting the error above (current ghc from darcs) | If you want I can give you an ssh account where this ghc version is | installed within the next days. | | I also had to add a -fglasgow-exts to a MemoTrie file.. | (Not sure which is the correct language extension which was missing) | | Sincerly | Marc Weber | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] Is this a feature or bug in the GADTs ExistentialQuantification? (Was: [Haskell-cafe] Unboxing VT_VARIANT in hscom)
(Redirecting to ghc-bugs.)
Krasimir, Praki
| The issue reported by Praki looks like a GHC bug to me.
I have compiled the two modules below with 6.8.3 and with the HEAD; both are
fine. If you have a reproducible case that fails, do please submit a Trac
report.
With HEAD you do need to add a type signature to useVariant :: Variant - IO
(), but then it's fine. The code I used is below.
Simon
| The smallest test case is at the end. (VarType a) is a GADT and
| Variant wraps the VarType with a value of type a. The definitions of
| Variant and VarType require ExistentialQuantification and GADTs
| extensions and I have declared them. The problem is when someone try
| to use them.
|
| If the client code is compiled without any extensions turned on the
| error message is:
|
| test.hs:35:47:
| Couldn't match expected type `IDispatch a'
| against inferred type `a1'
|`a1' is a rigid type variable bound by
| the constructor `Variant' at test.hs:34:22
| In the second argument of `getMethodID', namely `idisp'
| In a 'do' expression: dispId - getMethodID ExecQuery idisp
| In the expression:
| do dispId - getMethodID ExecQuery idisp
| return ()
|
| This suggests that the compiler understands that Variant is an
| existential type but doesn't understand that VarType is a GADT. If the
| code is compiled with -fglasgow-exts then everything works fine. Why
| the compiler always understands existential types and not GADT. For me
| this is unfair against GADT. Shouldn't the compiler always understand
| GADT as well provided that they are already defined somewhere?
|
| Best Regards,
| Krasimir
|
| --
| -- Implementation of Variant
| --
|
| {-# LANGUAGE ExistentialQuantification, GADTs #-}
| module Variant where
|
| data VarType a where
| VT_DISPATCH :: VarType IDispatch
|
| data IDispatch = IDispatch
|
| data Variant = forall a . Variant (VarType a) a
|
|
| --
| -- Use of Variant
| --
|
| import Variant
|
| useIDispatch :: IDispatch - IO ()
| useIDispatch _ = putStrLn useIDispatch
|
| useVariant :: Variant - IO ()
| useVariant (Variant VT_DISPATCH idisp) = useIDispatch idisp
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #2364: Make the maximum tuple size accesible
Or put it in Data.Tuple now, and re-export it from GHC.Exts?
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of GHC
| Sent: 22 June 2008 17:33
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: [GHC] #2364: Make the maximum tuple size accesible
|
| #2364: Make the maximum tuple size accesible
| -+--
| Reporter: fons | Owner:
| Type: feature request | Status: closed
| Priority: normal | Milestone: 6.10.1
| Component: Compiler |Version: 6.8.2
| Severity: normal | Resolution: fixed
| Keywords: | Difficulty: Unknown
| Testcase: | Architecture: Unknown
|Os: Unknown |
| -+--
| Changes (by igloo):
|
| * status: new = closed
| * difficulty: = Unknown
| * resolution: = fixed
| * milestone: = 6.10.1
|
| Comment:
|
| I've made it available in the HEAD:
| {{{
| Prelude GHC.Exts.maxTupleSize
| 62
| }}}
| We should probably put it somewhere more sensible, e.g. Data.Tuple, at
| some point.
|
| --
| Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2364#comment:1
| GHC http://www.haskell.org/ghc/
| The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: 6.8.3 against DoCon
| So, DoCon remains with ghc-6.8.2 -- untill GHC fixes the problem. | | Hm ... a small module needs 600 Mb instead of 80 Mb to compile, | and the release is considered as a progress. | All right, this may occur correct -- if the developers know what | namely must be fixed, and also know how to fix it. If so, then I could | believe. I have looked into this a bit. It's because GHC currently inlines every instance declaration bodily, code and all. DoCon has a lot of instance declarations with a lot of code in them, so there's a tremendous amount of code duplication as a result of dictionary construction. I've been working on a fix for this -- it bites every program, but DoCon especially -- but I have not yet managed to complete it. I'm not quite sure why 6.8.3 is worse than 6.8.2, but both are bad. I'm hoping for a dramatic improvement once I've done my fix. Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #2305: GHC does not care __RENAME macro
I've augmented the Using-the-FFI page too. I hope I got it right. http://haskell.org/haskellwiki/GHC/Using_the_FFI#Importing_C_functions_that_turn_out_to_be_CPP_macros Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of GHC | Sent: 05 June 2008 09:47 | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #2305: GHC does not care __RENAME macro | | #2305: GHC does not care __RENAME macro | -+-- | Reporter: iquiw| Owner: | Type: feature request | Status: closed | Priority: normal | Milestone: | Component: Compiler (FFI) |Version: 6.8.2 | Severity: normal | Resolution: invalid | Keywords: | Difficulty: Unknown | Testcase: | Architecture: Unknown |Os: NetBSD | | -+-- | Changes (by simonmar): | | * status: new = closed | * difficulty: = Unknown | * resolution: = invalid | | Comment: | | This is not a bug, as such - or rather, it's a bug in the via-C backend | that it actually works when compiling with -fvia-C (we fixed this recently | in HEAD). The FFI is defined to interface to the C ABI rather than the C | API; it doesn't take account of CPP magic. | | To work around this you typically need to call a C wrapper via the FFI | rather than calling the C function directly. The C wrapper lives in a .c | file and gets compiled by the C compiler. We have lots of these scattered | about the libraries already. | | -- | Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2305#comment:2 | GHC http://www.haskell.org/ghc/ | The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] Image manipulation
[Redirecting to ghc-bugs] | I'm not sure if the GC hack proposed by Wadler¹ that lets the garbage | collector replace fst (a,b) with a (and similar for other unchecked | selectors) counts as optimistic evaluation, but I wonder what the | status of this is. GHC doesn't seem to do it, and I wonder if there | is any particular reason? Too specific? | | GHC nominally does do it (look for 'selector thunks' in the RTS and | commentary), but it doesn't work and we don't know why. | | http://hackage.haskell.org/trac/ghc/ticket/1038 That bug is alleged to be fixed. Do you think it isn't? Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -O in 6.8.1-candidate
| In general the users should never have to modify the .cabal file. For | the common settings that we expect the user to want to control Cabal | provides configure flags. | | The idea is that instead of having to find the options for each | implementation you might want to use, that Cabal knows the right options | for each compiler to use a feature like optimisation or profiling or | whatever. You have a clear mental model of how Cabal is intended to be used -- although it also provides trapdoors (like ghc-options) for when the intended path isn't adequate. But that mental model is much clearer to you and the other Cabal developers than it is to Cabal users like Serge and me. Would it be worth writing a new section in the Cabal manual that describes the intended use model for Cabal, for the benefit of Cabal users? That way you'd be able to explain this stuff once and for all. Documentation often focuses on the knobs (turn the steering wheel to make the car change direction), and omit the larger mental model of what is going on (cars should be driven on a road). Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -O in 6.8.1-candidate
| By default cabal uses ghc -O to build projects, so you won't see any | difference if you comment it out of the cabal file. You will however | if you explicitly turn off optimisations: | | ghc-options: -Onot This is perhaps a bit confusing. Is it documented in the cabal manual? It's not documented under ghc-options in the currently-online manual. Are there any other flags there by default? Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug in 6.8.1-candidate
I'd go for 20070914 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20070914-src.tar.bz2 S | -Original Message- | From: Serge D. Mechveliani [mailto:[EMAIL PROTECTED] | Sent: 15 October 2007 15:41 | To: Simon Peyton-Jones | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: bug in 6.8.1-candidate | | On Mon, Oct 15, 2007 at 02:47:37PM +0100, Simon Peyton-Jones wrote: | | But it'd be better still to check with the 6.8 branch, but I can see you can't do that. IAN, are | we | | dumping snapshots of the 6.8 branch for people to try? Can you help Serge (and perhaps others) | have a | | snapshot they can try. | | Actually, Serge, you can find STABLE (i.e. 6.8 branch) snapshots here: | | http://haskell.org/ghc/download.html | | There's no Windows installer in the last few days, for reasons Simon is looking into, but the source | distributions should be fine. I'd wait until after tonight, to be sure Ian's merges have all gone in. | | Simon | | | Do you mean that | | http://haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071013-src.tar.bz2 | of October 13 | will do? | | --- | Mechveliani ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug in :browse (Re: ghci :browse! and type of class methods ([GHC] #1617))
Absolutely right! Thank you Claus, I will look into this.
Simon
| note that things are going wrong in this area even without my patch.
| consider this module
| --
| {-# OPTIONS_GHC -fglasgow-exts #-}
| module Main where
| class C a b where
| c1 :: Num b = a - b
| c2 :: (Num b,Show b) = a - b
| c3 :: forall a. a - b
| --
|
| and this ghci-6.6.1 session for it:
|
| *Main :b Main
| class C a b where
| c1 :: (Num b) = a - b
| c2 :: (Num b, Show b) = a - b
| c3 :: a - b
|
| *Main :t c3
| c3 :: (C a b) = a1 - b
|
| *Main :set -fglasgow-exts
| *Main :b Main
| class C a b where
| c1 :: (Num b) = a - b
| c2 :: (Num b, Show b) = a - b
| c3 :: forall a. a - b
|
| apparently, the printing of C uses dropForAlls on c3, without
| considering scope issues, so the output of that first browse is
| simply wrong. also, i wonder how the ghci-session can be in
| *Main without having -fglasgow-exts set? these issues are still
| with us in today's head.
|
| claus
|
| | class C a where c :: (Num b) = a - b
| | c :: C a - forall b. (Num b) = a - b
|
| I think the right thing here is to change Type.dropForAlls,
| so that it drops for-alls nested to the right of arrows. Then
| you'd get c :: (C a, Num b) = a - b
|
| yes, that makes sense. but i'm wary of those type-manipulating
| functions, as they only operate on the structure of the types,
| not seeming to look at scopes. what if the inner forall shadows
| a type variable binding from the outer forall? or, if i want to
| lift the inner forall outwards, what if the inner forall captures
| a type variable in the context? do i really have to do all this
| myself, just to print out the type associated with a name?
|
| | class C a where c :: forall b. (Num b) = a - b
| | c :: forall a. (C a) = forall b. (Num b) = a - b
|
| This *really is* c's type, so it's only honest to say so.
|
| shouldn't the correct type be something that would be
| valid source code as well?
|
| c :: forall a, b. (C a, Num b) = a - b
|
| the type shouldn't distinguish between class methods and
| other overloaded functions, should it?
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghci :browse! and type of class methods ([GHC] #1617)
| i would still like to know how one is supposed to display | the type of class methods, and why 'it' is not bound in the | same naive way i've used to bind 'output'. once these two About the it/output thing, I don't know. Can you be more explicit about what your question is? Concerning class methods... | *Main :b! Control.Monad | fail :: Monad m - forall a. String - m a I can't explain why this does not print as (Monad m) = ... I'll try applying your patch when I have a clean build to hand. | also, if the class method has its own context, as in: | | class C a where c :: Num b = a - b | | we get two levels of context, instead of a single merged context: | | *Main :b! Main | class C a where c :: (Num b) = a - b | c :: C a - forall b. (Num b) = a - b I think the right thing here is to change Type.dropForAlls, so that it drops for-alls nested to the right of arrows. Then you'd get c :: (C a, Num b) = a - b However, if you *ask* to display the foralls, then the only thing to do is to display the actual type, as you do here: | *Main :set -fglasgow-exts | | *Main :b! Main | class C a where c :: forall b. (Num b) = a - b | c :: forall a. (C a) = forall b. (Num b) = a - b This *really is* c's type, so it's only honest to say so. (I'm not sure why -fglasgow-exts switches on forall-printing; that seems odd. Is it really what GHC does? We should surely have a flag for that.) Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Request for inline control of warning level
| OPTIONS_GHC pragmas allow warnings to be enabled or disabled for a | particular file, but there are some limitations: | | * It doesn't override command-line settings (being tacked on the start, | rather than the end, of the options lists, I believe) I don't think this is right -- or if it is, it's a bug. The OPTIONS_GHC stuff is supposed to override command-line opts | * It doesn't work on sections of the code, but rather the whole file. True, and it'd be great to give more local pragma control -- a good feature request. Someone might want to work out details of the programmer's eye view and make a Trac feature request Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Vote for GHC 6.8 bugs!
Friends, We are gearing up towards at GHC 6.8 release. You can see details of what will be in it in the GHC status report for April http://hackage.haskell.org/trac/ghc/wiki/Status/April07. One symptom of the sharply-increased use of GHC is the sharply-increased number of bug reports and feature requests. We have no fewer than 200 milestoned for 6.8! You can see a summary here: http://hackage.haskell.org/trac/ghc/roadmap In reality we're unlikely to fix all 200, at least not without a lot of help from our friends. Inevitably, we have to prioritise. One way we do that is by using our (unreliable) perception of which bugs you (GHC's users) care about. This message is to invite you to improve the accuracy of this perception, by voting for the bugs you care about. We have just instituted a cheap-and-cheerful mechanism for voting. Each bug has a 'cc' field. To vote, just add your email address to the cc field! Better still, add a note to say why you care, and/or add a test case. We'll use the number of cc's (and an informal impression of any notes you've added) to guide our priorities. Adding yourself to the cc list means you'll get mail whenever anyone modifies the Trac report, which keeps you informed of what's going on. (You have to log in to edit Trac reports. Currently, new accounts are disabled for boring spammy reasons. That will be fixed when we upgrade Trac, but meanwhile, log in as guest, password guest.) It's not a perfect system, but we think it'll give useful extra guidance. So please go ahead and vote. But better still, help us fix bugs! GHC is open-source software, and it has a very large surface area (many platforms, many libraries, many features, documentation, tools, etc etc). Lots of people help make GHC good -- please join in (see the Joining in list in the GHC Wiki sidebar http://hackage.haskell.org/trac/ghc/wiki/) thanks Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: skipping module in .cabal
Just to make this 100% explicit: * Cabal uses ghc --make to build a bunch of .o files (including Match.o) * Cabal then links the .o files that are listed in dm.cabal (as exposed or other) to make a .a file. This list accidentally excludes Match.o * Cabal copies the .a file and the .hi files listed in dm.cabal (as exposed or other) to the install place, and registers them. Again, this list excludes Match.o As a result, a client of the package compiles all right (so long as it does not import Match) but fails at the link stage, lacking symbols in Match. This seems like a bug in Cabal, because it allows you to build and install an unusable package. Possible solutions I can think of: - Cabal does its own dependency analysis and calls GHC one module at a time - GHC gets a flag which prevents it finding any module other than those listed on the command line (although it may still do dependency analysis to figure out which order to compile them in) - The .cabal file is no longer reqd to list non-exposed modules. Instead Cabal works out what the non-exposed modules are (perhaps by calling GHC -M or something similar). Simon | -Original Message- | From: Duncan Coutts [mailto:[EMAIL PROTECTED] | Sent: 24 June 2007 04:33 | To: Serge D. Mechveliani | Cc: glasgow-haskell-bugs@haskell.org; Simon Peyton-Jones | Subject: Re: skipping module in .cabal | | On Sat, 2007-06-23 at 12:08 +0400, Serge D. Mechveliani wrote: | Dear GHC developers, | | Recently I submitted a bug report #1452 for ghc-6.6.1 | of undefined references at the stage of linking executable, | and also of ignoring un-existing module import. | | Now I discovered the following strange effect | (see the report source modules) which, probably, explains much. | | 1. (minor note) The file Match.hs-boot is not needed. | All the effects preserve after its removal. | | 2. The name `Match' must be in the list `other-modules:' | in the file | dm.cabal,which describes the package. | | But it is not in dm.cabal ! | Because I have forgotten to put it there. | | Currently Cabal uses ghc --make to build packages. It starts from all | the modules listed in the exposed-modules but ghc --make will find any | other modules that are imported, even if they are not listed in | the .cabal file in the exposed-modules or other-modules fields. | | That's the current system. The right system I think is for Cabal to do | the dependency analysis itself (it needs to do that for proper support | of pre-processors anyway). That would allow Cabal to notice when | modules | are imported but not listed in either the exposed-modules or | other-modules fields. It could issue a warning or an error. | | Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: un-existing import in boot-module
Hi Serge Can you give us a test case? And if so, submit a Trac bug report? It works ok for me (see my example below), so I can't do anything without more info. Simon sh-2.04$ cat D.hs-boot module D where import BadModule data X sh-2.04$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6.1 sh-2.04$ ghc -c D.hs-boot D.hs-boot:2:0: Failed to load interface for `BadModule': Use -v to see a list of the files searched for. sh-2.04$ | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell- | [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani | Sent: 21 June 2007 17:04 | To: glasgow-haskell-bugs@haskell.org | Subject: un-existing import in boot-module | | Dear GHC developers, | | ghc-6.6.1 does not report about unknown module import in boot-modules. | | For example, let us haveFoo.hs and Foo.hs-boot, | and add to Foo.hs-boot the line | | import M | | , where M is not a name of any existing module. | ghc `makes' the project without any report of this `M'. | | - | Serge Mechveliani | [EMAIL PROTECTED] | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] ambiguous record field names which actually aren’t ambigious
[Redirecting to ghc-bugs]
| module A where
| data A = A { label :: Int }
|
| module B where
| data B = B { label :: Int }
|
| b :: B
| b = B { label = 0 }
|
| x :: B - ()
| x B { label = 0 } = ()
|
| GHC reports an ambiguity for both usages of label.
Are you sure? Module B doesn't even import A!
And if you mean that B does import A, then Haskell 98 indeed says it's
ambiguous.
Now, it's true that in the case of both
a) pattern matching
b) record construction
there's a lot less ambiguity, because you know which *data constructor* is
involved. (Even better than knowing which module is involved. But for
c) record update (x { label = 0 })
d) field selection (label x)
you have no such clues.
Haskell could be defined to take advantage of (a) and (b), but if it was then
it'd *also* work if data A and data B were defined in the same module, and
Section 3.15 of the Haskell Report clearly states otherwise.
I conclude that Hugs is not implementing Haskell 98 here. In fact there's
clearly a bug in Hugs:
module A where
data A = A { foo :: Int }
module B where
import A
data B = B { foo :: Bool }
a = A {foo=3}
yields:
ERROR B.hs:8 - Constructor A does not have selected fields in A{foo
= 3}
Commenting out the declaration of data B makes the definition of 'a' work. I'm
ccing hugs-bugs.
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] ambiguous record field names which actually aren’t ambigious
| But wouldn’t it be worthwhile to allow this kind of stuff as a language | extension? It would make life easier in a couple of situations. I don’t | like the idea of using advanced record implemenations based on contended | language extensions (undecidable instances, etc.), thereby probably loosing | pattern matching, just to get rid of the need to qualify field names. :-( By all means! Make a feature request for GHC, as precisely stated as possible. (Better still, implement it.) Remember that you don't always get rid of the need to qualify field names, just in cases (a) and (b). S ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: main main main main main
That's odd. The file 'bayesian-sets.hs' starts by saying module Main where and it certainly defines the function 'main'. I can't see why GHC would report that it's not defined. It's hard to help, since you say it's not reproducible. As to the wording of the error message. Haskell requires that the module 'Main' defines a function called 'main'. The error message is trying to say that you have disobeyed this rule. (Apparently wrongly in this case.) You say that the wording is not human-friendly, and by definition you are right (you found it confusing). Can you suggest a more human-friendly way to say that you have failed to define 'main' in module 'Main'? Thanks Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 12 May 2007 22:14 | To: glasgow-haskell-bugs@haskell.org | Subject: main main main main main | | Hello, | | I'm suddenly getting the following error when I compile a program: | | bayesian-sets.hs:1:0: | The main function `main' is not defined in module `Main' | When checking the type of the main function `main' | | I don't know what that means. Perhaps the error could be made more | human-friendly? Here is the output of 'ghc -v': | | [1]$ ghc -v --make $A.hs -package vectro -lstdc++ -fallow-incoherent- | instances | Glasgow Haskell Compiler, Version 6.6.20070420, for Haskell 98, compiled | by GHC version 6.6.20070420 | Using package config file: /home/frederik/arch/i386//lib/ghc- | 6.6.20070420/package.conf | Using package config file: /home/frederik/.ghc/i386-linux- | 6.6.20070420/package.conf | wired-in package base mapped to base-2.0 | wired-in package rts mapped to rts-1.0 | wired-in package haskell98 mapped to haskell98-1.0 | wired-in package template-haskell mapped to template-haskell-2.0 | Hsc static flags: -static | *** Chasing dependencies: | Chasing modules from: bayesian-sets.hs | Stable obj: [] | Stable BCO: [] | compile: input file bayesian-sets.hs | Created temporary directory: /tmp/ghc8785_0 | *** Checking old interface for main:Main: | [1 of 1] Compiling Main ( bayesian-sets.hs, bayesian-sets.o ) | *** Parser: | *** Renamer/typechecker: | | bayesian-sets.hs:1:0: | The main function `main' is not defined in module `Main' | When checking the type of the main function `main' | *** Deleting temp files: | Deleting: /tmp/ghc8785_0/ghc8785_0.s | Warning: deleting non-existent /tmp/ghc8785_0/ghc8785_0.s | Upsweep partially successful. | *** Deleting temp files: | Deleting: | link(batch): upsweep (partially) failed OR |Main.main not exported; not linking. | *** Deleting temp files: | Deleting: | *** Deleting temp dirs: | Deleting: /tmp/ghc8785_0 | | Thanks, | | Frederik | | -- | http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc-6.6: panic! (the 'impossible' happened)
Jared
Do please open a Trac bug report and attach the code that provokes this. Or
just send the code.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Jared Updike
| Sent: 03 February 2007 08:17
| To: glasgow-haskell-bugs@haskell.org
| Subject: ghc-6.6: panic! (the 'impossible' happened)
|
| ghc-6.6: panic! (the 'impossible' happened)
| (GHC version 6.6 for i386-apple-darwin):
| checkKind: adding kind constraint
| t{tv a2M5} [tv] *
| t_a1pL{tv} [tau] t_a1pL{tv} [tau] ??
|
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| ---
|
| If you want the code that can cause this to happen on a Mac, let me
| know, just thought I'd report this since GHC said to.
|
| Jared.
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bad error message with GADTs
This is a bug, or at least infelicity, in 6.6. I'm not inclined to fix it,
unless something worse happens, because it's ok in the HEAD.
I will add a regression test though!
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-
| [EMAIL PROTECTED] On Behalf Of Donald Bruce Stewart
| Sent: 30 November 2006 00:38
| To: David Roundy
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: bad error message with GADTs
|
| droundy:
| The following code gives a rather unpleasant error message with ghc
| 6.6.
| Adding the type signature fixes the error.
|
| David
|
| {-# OPTIONS -fglasgow-exts #-}
|
| data PatchSeq p a b where
| Nil :: PatchSeq p a a
| U :: p a b - PatchSeq p a b
| (:-) :: PatchSeq p a b - PatchSeq p b c - PatchSeq p a c
|
| -- is_normal :: PatchSeq p a b - Bool
| is_normal Nil = True
| is_normal (U _) = True
| is_normal (U _ :- _) = True
| is_normal _ = False
| ___
|
| I.e. this one?
|
| A.hs:9:10:
| Couldn't match kind `?' against `* - * - *'
| When matching the kinds of `t :: ?' and `t1 :: * - * - *'
| Expected type: t1
| Inferred type: t
| In the pattern: Nil
|
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] Weird field name mangling.
[Redirecting to ghc-bugs]
That's a bug in 6.4.1 thank you. The reason has to do with z-encoding strings
in case they are output to C-land.
Happily the bug is not present in 6.6; I doubt we'll fix 6.4.1 now.
I've added a test to make sure it does not creep back: drvrun022
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arthur van
| Leeuwen
| Sent: 22 November 2006 16:59
| To: haskell@haskell.org
| Subject: [Haskell] Weird field name mangling.
|
| L.S.,
|
| consider the following code:
|
| module TestZ where
|
| import Data.Generics
|
| data TestZ = TestZ { testz :: Int }
|deriving (Show, Read, Eq, Typeable, Data)
|
| main = print $ constrFields . toConstr $ TestZ { testz = 2 }
|
| I would expect this to output [testz]. Instead it outputs [testzz],
| using GHCi 6.4.1. Why is that z doubled?
|
| Doei, Arthur.
|
| --
|
|/\/ | [EMAIL PROTECTED] | Work like you don't need
| the money
| /__\ / | A friend is someone with whom | Love like you have never
| been hurt
| /\/__ | you can dare to be yourself | Dance like there's nobody
| watching
|
|
|
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: confusing Warning: Imported from
Good point, thank you. I've fixed this. (Ian: I'm not certain that the patch will smoothly move to the branch, but the same idea will apply there.) * Improve handling of unused imports (test is mod75) Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Christian Maeder | Sent: 20 October 2006 13:58 | To: glasgow-haskell-bugs@haskell.org | Subject: confusing Warning: Imported from | | line 12 and 13 of my source ATC2.hs | (http://hackage.haskell.org/trac/ghc/ticket/955) | are: | | import HsName (HsName(UnQual)) | import PropPosSyntax | | UnQual comes in via PropPosSyntax and HsName but is not used. | | However, I would expect a warning for my explicit import of UnQual from | HsName. Instead I get: | | ATC2.hs:13:0: | Warning: Imported from `PropPosSyntax' but not used: |data constructor `UnQual' | | Is this a known (or easy to resolve) issue? | | Christian | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghci 6.4 panic on HList code.
Yes, this is indeed a bug, happily long fixed. 6.6 says Foo9.hs:1:34: Class `C' used as a type In the class declaration for `C' Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Matthias Fischmann | Sent: 06 October 2006 15:03 | To: glasgow-haskell-bugs@haskell.org | Subject: Re: ghci 6.4 panic on HList code. | | | | sorry, i was too fast with my report. i still consider what i found a | bug in ghci, but it's triggered by a bug in my code. you can also | trigger it by the much shorter: | | module Main where class C a where f :: C a | | in contrast, the more correct: | | module Main where class C a where f :: a | | works. feel free to fix it anyhow, of course... (-: | | cheers, | matthias F25 0996 4D73 F1FD 8D32 9BAA ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Summary of GHC 6.6 test suite failures on MSYS/MinGW
Dont worry about Maessen_hashtab. It fails core Lint, and its on my list to look at. (Its been failing for some time) S From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Smith Sent: 13 September 2006 18:23 To: glasgow-haskell-bugs@haskell.org Subject: Summary of GHC 6.6 test suite failures on MSYS/MinGW I finished re-running the test suite with all the necessary libraries installed. Here are the tests that are failing: make stage=2 TESTS=TH_exn TH_fail cabal01 cabal02 conc023 conc037 conc049 conc056 ffi012 ghcpkg04 maessen_hashtab readwrite002 tcfail115 tcfail140 utf8_002 utf8_003 utf8_004 utf8_005 Of particular concern is maessen_hashtab because it segfaults during the test. Below is a brief description of the result of each test. For many of these tests, I do not yet know enough to fix them. But, hopefully this report will be helpful to somebody else. Regards, Brian * maessen-hashtab This test segfaults, dereferencing a null pointer. This happens every way (normal,opt,optasm,prof,profasm,ghci,threaded1,threaded2) it gets run. The error message printed is too long to repeat here. I have no idea what the problem is. * utf8_002, utf8_003, utf8_004, utf8_005: These tests all fail the same way, outputing: utf8_002.hs:2:0: lexical error at end of input instead of: utf8_002.hs:2:0: lexical error (UTF-8 decoding error) * readwrite002 This program complains to stderr: readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument) and to stdout: ### Caught EOF ### Caught EOF ### Caught EOF * TH_exn(normal) TH_fail(normal) These two fail because the GHC indents the pretty-printed code in the error message differently than expected. * conc023(ghci) This test only fails when run via GHCi. This test runs out of memory. The error message to stderr is: conc023: failed to create OS thread: Not enough storage is available to process this command. When I came back to the computer I saw that Windows was warning me that I was out of virtual memory and that it was increasing my page file size. I have 1GB of RAM which I think should be sufficient to run the testsuite successfully. * conc037(threaded2) This test prints the output in a different order than expected, but I don't know enough about how Control.Concurrent is supposed to work to know if the problem is in GHC or in the test. Please note that I am running the tests on a dual core (Core Duo) processor: ! newThread started ! mainThread ! newThread back again ! 1 sec later ! ! shutting down --- 1,6 ! mainThread ! newThread started ! newThread back again ! 1 sec later ! ! shutting down * ffi012(ghci) This happens only when run via GHCi. The following error message is issued instead of the expected output: During interactive linking, GHCi couldn't find the following symbol: Main_d1d4 This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org ghcpkg04(normal) An error message different than the expected. I didn't investigate this one too closely: ! ! ghcpkg04.hs:1:0: ! Failed to load interface for `A': ! it was found in multiple packages: testpkg-1.2.3.4 newtestpkg-2.0 --- 1,4 ! ! ghcpkg04.hs:1:0: ! Failed to load interface for `A': ! Use -v to see a list of the files searched for. * tcfail115, tcfail140 The error messages output by GHC are very different than the expected ones. No clue as to why though. * cabal01, cabal02 These fail because Cabal won't work when the GHC executable is actually a shell script on Windows. * process001, process002, prog001, prog002, prog003 These fail because they depend on executables (ls, rm) that are not available on Windows. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: impossible happened: splitTyConApp a{tv i6hr}
OK, I can reproduce it now. (Previously I was not compiling with -O2.)
It's a bug in 6.4.2 related to GADTs, specifically in the typing of
interface files. You get a much more informative message if you use the
flag -dcore-lint.
I think it's fixed in the upcoming 6.4.3 release; at least it works for
me.
Can you try to download a snapshot distribution of 6.4.3 (the STABLE
branch) from
http://www.haskell.org/ghc/download.html
and try that?
Simon
| -Original Message-
| From: Frederik Eaton [mailto:[EMAIL PROTECTED]
| Sent: 16 August 2006 15:48
| To: Simon Peyton-Jones
| Subject: Re: impossible happened: splitTyConApp a{tv i6hr}
|
| Here:
|
| http://ofb.net/~frederik/gslhaskell2-ghc-bug1.tar.gz
|
| The file General.hs is the subdirectory Vector.
|
| The problem only happens when I edit General.hs and recompile...
|
| Frederik
|
| On Wed, Aug 16, 2006 at 03:30:02PM +0100, Simon Peyton-Jones wrote:
| I'd like to reproduce this, but to do so I'll need either a cut-down
| version, or all the source code need to get to the point where it
fell
| over. Could you manage the former, or if not, the latter? Thanks
|
| S
|
| | -Original Message-
| | From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]
| | On Behalf Of Frederik Eaton
| | Sent: 16 August 2006 14:52
| | To: glasgow-haskell-bugs@haskell.org
| | Subject: impossible happened: splitTyConApp a{tv i6hr}
| |
| | I've attached the code.
| |
| | Skipping Vector ( Vector.hs, dist/build/Vector.o )
| | Compiling Vector.General ( ./Vector/General.hs,
| dist/build/Vector/General.o )
| |
| | ./Vector/General.hs:29:0:
| | Warning: No explicit method nor default method for
| `vectorUpdate'
| | In the instance declaration for `Vector (GVector e)
e'
| |
| | ./Vector/General.hs:29:0:
| | Warning: No explicit method nor default method for `byRow'
| | In the instance declaration for `Vector (GVector e)
e'
| | ghc-6.4.2: panic! (the `impossible' happened, GHC version
6.4.2):
| | splitTyConApp a{tv i6hr}
| |
| | Please report this as a compiler bug. See:
| |http://www.haskell.org/ghc/reportabug
| |
| | --
| | http://ofb.net/~frederik/
|
|
| --
| http://ofb.net/~frederik/
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [GHC] #840: GHC on loosing its handles takes 100% CPU
I'm not doubting that it's genuine -- but can anyone make a reproducible test case? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Lennart Augustsson | Sent: 04 August 2006 13:47 | To: Bulat Ziganshin | Cc: GHC; glasgow-haskell-bugs@haskell.org | Subject: Re: [GHC] #840: GHC on loosing its handles takes 100% CPU | | It happens all the time to me that GHC doesn't die properly on windows. | Every so often I have to kill a few straggling ghc processes. They | all spin consuming 100% CPU when this happens. | | -- Lennart | | On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote: | | Hello GHC, | | Wednesday, August 2, 2006, 4:33:09 PM, you wrote: | | #840: GHC on loosing its handles takes 100% CPU | | import System.Process | main = runInteractiveCommand ghc | | When run terminates immediately, as expected, but leaves an instance | of ghc running. The ghc process takes up 100% of the CPU time, and | seemingly does nothing. | | well, i have similar problem: there are only 256 megs on my machine | and sometimes when ghc compilation uses more than 200 megs and starts | trashing memory, i tries to stop it by hitting Ctrl-C. in this | situation it's rather typical that i got back my console (and rerun | ghc) but old GHC process don't killed and continue to compile program. | i can investigate it further but don't know what to do. at least it | seems that memory trashing is required to uncover this problem. i also | should note that i run ghc --make from the .cmd file so there is a | whole stack of processes runned. may be i just kill higher-level ghc | (or even cmd) and lower-level ghc still continue to do it's job? i'm | not sure.. | | -- | Best regards, | Bulatmailto:[EMAIL PROTECTED] | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHCi on loosing its handles takes 100% CPU
Simon and I have no idea what's going on here. It doesn't happen for me (on my Windows laptop). Can anyone else reproduce this behaviour? If so, is anyone willing to dive in a bit deeper and find out more about what is going on? Regardless, creating a Trac bug report would ensure it doesn't lost. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Neil Mitchell | Sent: 29 July 2006 20:16 | To: glasgow-haskell-bugs@haskell.org | Subject: GHCi on loosing its handles takes 100% CPU | | Hi | | On Windows, GHC 6.4.2, the following program: | | import System.Process | main = runInteractiveCommand ghc | | When run terminates immediately, as expected, but leaves an instance | of ghc running. The ghc process takes up 100% of the CPU time, and | seemingly does nothing. | | If ghci is used as the argument instead of ghc, then both ghc and | ghci are left running, with ghc on 100% CPU time. | | In contrast, if hugs or Yhc or edit (or pretty much any program on my | system) is run in exactly the same way, they terminate as soon as the | main program is finished. | | Is there any chance that GHC could do this too? | | Thanks | | Neil ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: unsafeCoerce#
Good idea. There's suitable section here in the HEAD manual, here: http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.htm l#id3159468 I'll add a subsection about unsafeCoerce# Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Neil Mitchell | Sent: 31 July 2006 00:45 | To: glasgow-haskell-bugs@haskell.org | Subject: unsafeCoerce# | | Hi, | | Finding unsafeCoerce# in the documentation is challenging at best. | It's not indexed by Haddock, which in turn means its not indexed by | Hoogle. Lambdabot doesn't find it. Googling gave me GhcExts (from an | old Happy file), which I guessed at GHC.Exts. | | Someone in #haskell suggested GHC.Base. I'm not sure where I should | import it from, but it would be nice if the docs included it | somewhere. | | Thanks | | Neil | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GADTs and infix?
Because I am an idiot. Now fixed -- thank you for pointing it out. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Conal Elliott | Sent: 17 July 2006 18:52 | To: glasgow-haskell-bugs@haskell.org | Subject: GADTs and infix? | | In ghc 6.5, why does this GADT definition get accepted | | data DArrowX :: * - * - * where |First :: DArrowX a a' - DArrowX (a,b) (a',b) | | and also this one | | data DArrowX :: * - * - * where |First :: a `DArrowX` a' - DArrowX (a,b) (a',b) | | but this not one | | data DArrowX :: * - * - * where |First :: a `DArrowX` a' - (a,b) `DArrowX` (a',b) | | which yields | | Malformed constructor signature: (a, b) DArrowX (a', b) | In the signature of a data constructor: a DArrowX a' - (a, b) | DArrowX (a', b) | In the data type declaration for `DArrowX' | | Is this a bug? | | - Conal | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: unexpected arithmetic sequence and deriving Enum behaviour
| one, and the program compiles. Interestingly, -ddump-deriv doesn't
show
| anything about deriving instances for Colour, yet, obviously
something
| gets derived.
For me (ghc 6.4.2) it says:
Derived instances
InstInfo: {GHC.Show.Show Foo4.Colour}
{ GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0)
GHC.Show.showsPrec (_) (Foo4.Red) = GHC.Show.showString Red
GHC.Show.showsPrec (_) (Foo4.Black) = GHC.Show.showString Black
GHC.Show.showsPrec (_) (Foo4.Blue) = GHC.Show.showString Blue }
InstInfo: {GHC.Enum.Bounded Foo4.Colour}
{ GHC.Enum.maxBound = Foo4.Blue
GHC.Enum.minBound = Foo4.Red }
Not very pretty, but definitely not nothing.
| When you run it, it dies with an error message from 'toEnum n' (or
| non-exhaustive pattern if you leave that one out).
That's exactly as specified by the Report. If you look here,
http://haskell.org/onlinereport/standard-prelude.html
and search for class Enum, you'll se
class Enum a where
..[snip]...
-- NOTE: these default methods only make sense for types
-- that map injectively into Int using fromEnum
-- and toEnum.
enumFrom x = map toEnum [fromEnum x ..]
and this is precisely the behaviour you get.
I agree it isn't the behaviour your want. If every Enum was Bounded,
the enumFrom default method could stop at maxBound. But Enum and
Bounded are separate classes.
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: External Core: %local tag
External Core is a bit of an orphan at the moment. It lacks someone to love it and keep it up to date. Anyone who'd like to take on this role would be very welcome! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Jan Rochel | Sent: 15 June 2006 18:25 | To: glasgow-haskell-bugs@haskell.org | Subject: External Core: %local tag | | Hello, this is not really a bug-report. | | I'm currently busy with some programming involving hcr files. | I noticed that GHC does not make use of the %local-tag as it is specified in | An External Representation for the GHC Core Language (DRAFT for GHC5.02) on | page 3. | I'd be very grateful if anyone who feels competent/responsible fixed this. | If demanded, I'd submit a patch for this, but actually I don't yet feel worthy | modifying the glorious Glasgow Haskell Compiler. | | Regards | Jan | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: the impossible happened: splitTyConApp
A nice bug report, thank you. Turns out to be an obscure GADT case, and
another reason for switching to System FC.
I've fixed the STABLE branch, but I won't fix the HEAD because we're
about to move to FC so it seems hardly worth it.
BUT if we release the HEAD before the FC switch, we should apply the
patch from the STABLE branch.
Meanwhile, as a workaround, compile without -O. Or even just compile
Vector.Fast without -O
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| On Behalf Of Frederik Eaton
| Sent: 11 June 2006 17:33
| To: glasgow-haskell-bugs@haskell.org
| Subject: the impossible happened: splitTyConApp
|
| Hi,
|
| $ ghc -O3 --make LearnBinFactors.hs -package GSL -o lbf
| Chasing modules from: LearnBinFactors.hs
| Compiling Main ( LearnBinFactors.hs, LearnBinFactors.o )
| ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):
| splitTyConApp a{tv a8EX}
|
| I've attached the program LearnBinFactors.hs.
|
| The version of the GSL package which it uses can be downloaded from:
|
| http://ofb.net/~frederik/GSLHaskell2.tar.gz
|
| Frederik
|
| --
| http://ofb.net/~frederik/
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: the impossible happened - size limits in template haskell?
Yes, this is a bug, with an unhelpful error message. We've opened a Trac bug for it, but at low priority. Thanks for reporting it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 05 June 2006 06:25 | To: glasgow-haskell-bugs@haskell.org | Subject: the impossible happened - size limits in template haskell? | | Here I'm reading a very large matrix from a file and turning it into a | template Haskell expression. Probably not the most efficient thing to | do, but the error message could be clearer... | | *Main let y = $(qFast (\f - runIO $ readMatrixFile data.txt (runQ.f))); | ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2): | linkBCO: = 64k insns in BCO | | Please report this as a compiler bug. See: | http://www.haskell.org/ghc/reportabug | | | | -- | http://ofb.net/~frederik/ | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] Edison 1.2 and profiling
[Redirecting to GHC bugs] We'd like to reproduce this. Can you submit a Trac bug (http://www.haskell.org/ghc/reportabug), including your source code? Could conceivably be the same problem as http://hackage.haskell.org/trac/ghc/ticket/778 Thanks Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mario Blazevic | Sent: 04 June 2006 17:36 | To: haskell@haskell.org | Subject: [Haskell] Edison 1.2 and profiling | | | The profiled version of the latest Edison library doesn't work for me. | | I got Edison 1.2 via darcs. I used the regular 'make system' command to | build and install the regular (non-profiled) version of Edison. Then I | went to edison-api and edison-core subdirectories, in turn, and executed | the Cabal commands: | | runhaskell Setup.hs clean | runhaskell Setup.hs configure --enable-library-profiling | runhaskell Setup.hs build | runhaskell Setup.hs install | | | The library seems to be properly installed: | | $ ls -l /usr/local/lib/EdisonCore-1.2/ghc-6.4.2/ | total 9985 | drwxr-xr-x 3 root root 72 Jun 3 20:28 Data | -rw-r--r-- 1 root root 1939264 Jun 4 12:08 HSEdisonCore-1.2.o | -rw-r--r-- 1 root root 2932114 Jun 4 12:08 libHSEdisonCore-1.2.a | -rw-r--r-- 1 root root 5339788 Jun 4 12:08 libHSEdisonCore-1.2_p.a | | $ ls -l /usr/local/lib/EdisonCore-1.2/ghc-6.4.2/Data/Edison/Assoc/ | total 720 | -rw-r--r-- 1 root root 86508 Jun 4 12:08 AssocList.hi | -rw-r--r-- 1 root root 86513 Jun 4 12:08 AssocList.p_hi | -rw-r--r-- 1 root root 61267 Jun 4 12:08 Defaults.hi | -rw-r--r-- 1 root root 61272 Jun 4 12:08 Defaults.p_hi | -rw-r--r-- 1 root root 67740 Jun 4 12:08 PatriciaLoMap.hi | -rw-r--r-- 1 root root 67745 Jun 4 12:08 PatriciaLoMap.p_hi | -rw-r--r-- 1 root root 56208 Jun 4 12:08 StandardMap.hi | -rw-r--r-- 1 root root 56213 Jun 4 12:08 StandardMap.p_hi | -rw-r--r-- 1 root root 86239 Jun 4 12:08 TernaryTrie.hi | -rw-r--r-- 1 root root 86244 Jun 4 12:08 TernaryTrie.p_hi | | I compile the profile version of my program using the following line: | | ghc -package text -package EdisonAPI -fglasgow-exts --make Main -o | gens-prof -odir profiler -hidir profiler -prof -auto-all | | The ghc version is 6.4.2, by the way. When I run the compiled program, | it keeps grabbing memory until it's killed by the system. The | non-profiled version of the program runs perfectly well. In fact, the | PatriciaLoMap from Edison seems to be about two to three times faster | than Data.Map library for my purposes. Lots of unions. So you might say | that I don't need profiling any more, but still... | | Any ideas on what might have gone wrong? | | ___ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Show Bug (I think)
True, thank you. I'm fixing it as we speak. drvrun020 is the test.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Neil Mitchell
| Sent: 30 April 2006 19:10
| To: glasgow-haskell-bugs@haskell.org
| Subject: Show Bug (I think)
|
| Hi,
|
| ---
| data Item = Item1 Item
| | Item2 {a :: Int}
| deriving (Show, Read)
|
| value = Item1 (Item2 1)
|
| valueHugs = Item1 Item2 {a = 1}
| valueGhc = Item1 (Item2 {a = 1})
|
| readItem x = (read x) :: Item
| --
|
| With the following code show value under Hugs and Ghc give different
| results. readItem valueHugs and valueGhc both succeed under Hugs, but
| readItem valueHugs fails under GHC.
|
| I guess this is a bug with GHC, since that text for valueHugs on the
| command line succeeds with GHCi - i.e. typed directly not with read.
|
| Hugs: WinHugs CVS
| GHC: 6.4.2 Windows
|
| Thanks
|
| Neil
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: TH, tuples and impossible happened problem
I'm sorry I've been slow in replying to this.
Short summary: your program has a bug, but GHC still should not crash.
The bug is that you extracted the Name of the *type constructor* (,,) from the
type of 'x, but you then used it as a *data constructor* in the pattern.
Solution: when you have the Name of the type constructor, use 'reify' again to
get the data constructors.
Meanwhile I will make GHC complain more gracefully.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Václav Haisman
| Sent: 19 March 2006 16:06
| To: glasgow-haskell-bugs@haskell.org
| Subject: TH, tuples and impossible happened problem
|
| Hi,
| I have a little problem with Template Haskell. I have been trying make a
| template function that would allow me to read any element of tuple
| without explicit knowledge of how wide the tuple is. I have done some
| code but recently I have been stopped by GHC's impossible happened:
|
|
| Compiler output:
|
| Chasing modules from: MyTHUse.hs
| Compiling MyTH ( ./MyTH.hs, ./MyTH.o )
| Compiling Main ( MyTHUse.hs, MyTHUse.o )
| Loading package base-1.0 ... linking ... done.
| Loading package haskell98-1.0 ... linking ... done.
| Loading package template-haskell-1.0 ... linking ... done.
| ghc: panic! (the `impossible' happened, GHC version 6.4.1):
| tyThingDataCon Type constructor `DataziTuple.Z3T{(w) tc 49}'
|
| Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
|
| --
| MyTH.hs:
|
| module MyTH where
|
| import Language.Haskell.TH
| import Language.Haskell.TH.Syntax
| import Language.Haskell.TH.Ppr
|
| -- TI data_constructor param_count
| data TupleInfo = TI Name Int
|
| --
| getTupleInfo :: Name - Q TupleInfo
| getTupleInfo var_name =
| do
| info - reify var_name
| case info
| of
| vi@(VarI _ typ _ _) -
| case typ
| of
| appt@(AppT _ _) - return $ traverseAppT 0 appt
| _ - error Not a tuple-like type.
| _ - error Not a variable.
| where
| traverseAppT n (AppT t1 _) = traverseAppT (n+1) t1
| traverseAppT n (ConT name) = TI name (n+1)
|
| --
| tupleGet :: Name - Int - Q Exp
| tupleGet var_name tuple_index =
| do
| (TI constr_name width) - getTupleInfo var_name
| param_name - newName tuple_elem_
| sub_patterns - genPattern 1 width tuple_index param_name
| lambda -
| lamE [conP constr_name (map return sub_patterns)]
| (varE param_name)
| return lambda
| where
| genPattern counter n param_index param_name
|| counter == (n+1) = return []
|| counter == param_index =
|do
|p - varP param_name
|rest - genPattern (counter+1) n param_index param_name
|return (p:rest)
|| otherwise =
|do
|wp - wildP
|rest - genPattern (counter+1) n param_index param_name
|return (wp:rest)
|
| --
| MyTHUse.hs:
|
| import MyTH
| import System.IO
| import Language.Haskell.TH
| import Language.Haskell.TH.Syntax
| import Data.Tuple
|
| x = (1,2,3)
|
| get1Of3 = $(tupleGet 'x 1)
|
|
| --
| Vaclav Haisman
|
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Template Haskell
Thank you for the bug report. It certainly is a bug. I'm fixing it now. Sadly, I've missed the boat for GHC 6.4.2, but the fix will be in the HEAD, and in the next release. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] | Sent: 15 March 2006 12:33 | To: glasgow-haskell-bugs@haskell.org | Subject: Template Haskell | | Hi, | | i've got a problem with the function recover in Template Haskell: | | I'd like to check, if a function is already implemented. My idea is to | call reify with the functionname. But reify throws an error if the name is | not in scope. So I wanted to use recover, but it doesn't work like | expected: | | y = $(recover (return (LitE (IntegerL 1))) |(reify (mkName (ola)) return (LitE (IntegerL 2 | | The compilation failed: `ola' is not in scope at a reify | In the definition of `y' | I thought the value of y would be 1, if ola is not in scope and 2 | otherwise. | | | And even this doesn't work (the compilation failed): | | x = $(recover (return (LitE (IntegerL 1))) |(report True error return (LitE (IntegerL 2 | | | Is there a bug in recover? | | Melanie Bargstädt | | | | | | | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: quoting in error messages
What do others think? It'd be dead easy to replace `thing' by thing in GHC's error messages, if that's what a majority want. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 07 April 2006 13:40 | To: glasgow-haskell-bugs@haskell.org | Subject: quoting in error messages | | Hi, | | This is quite a minor issue but I just wanted to point out that it | would be a little easier on the eye to use double quotes rather than | paired single quotes in error messages e.g.: | | Couldn't match the rigid variable `d'' against `Bar a' | `d'' is bound by the polymorphic type `forall d d'. | (Data d, Data d') = | t d d' - t d d'' | | Thanks, | | Frederik ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: overlapping instances in ghc-6.5
OK now I understand. For some time, GHC has made -fallow-overlapping-instances sticky: any instance in a module compiled with -fallow-overlapping-instances can overlap when imported, regardless of whether the importing module allows overlap. (If there is an overlap, both instances must come from modules thus compiled.) The trouble is that Data.Typeable wasn't being compiled with -fallow-overlapping-instances. I've committed a fix that makes it so. Simon | -Original Message- | From: Christian Maeder [mailto:[EMAIL PROTECTED] | Sent: 06 February 2006 13:12 | To: Simon Peyton-Jones | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: overlapping instances in ghc-6.5 | | The attached 4 files compile with ghc-6.4.1 and fail with | ghc-6.5.20060201 (see below). | | Also, if I delete the Int and Integer instances in | Common/ATerm/Conversion.hs the error remains the same for ghc-6.5 | whereas ghc-6.4.1 correctly complains about | No instance for (ShATermConvertible Int) |arising from use of `fromShATerm'' at | Common/ATerm/ConvInstances.hs:39:25-36 | | (Common.Lib.Graph is basically the same as Data.Graph.Inductive.Tree) | | Cheers Christian | | ghc --make -no-recomp -fglasgow-exts -fallow-overlapping-instances | Common/ATerm/ConvInstances.hs | Chasing modules from: Common/ATerm/ConvInstances.hs | [1 of 4] Compiling Common.ATerm.AbstractSyntax ( | Common/ATerm/AbstractSyntax.hs, Common/ATerm/AbstractSyntax.o ) | [2 of 4] Compiling Common.ATerm.Conversion ( Common/ATerm/Conversion.hs, | Common/ATerm/Conversion.o ) | [3 of 4] Compiling Common.Lib.Graph ( Common/Lib/Graph.hs, | Common/Lib/Graph.o ) | [4 of 4] Compiling Common.ATerm.ConvInstances ( | Common/ATerm/ConvInstances.hs, Common/ATerm/ConvInstances.o ) | | Common/ATerm/ConvInstances.hs:31:0: | Overlapping instances for Typeable (Common.Lib.Graph.Gr a b) |arising from the superclasses of an instance declaration at | Common/ATerm/ConvInstances.hs:31:0 | Matching instances: |instance (Typeable1 s, Typeable a) = Typeable (s a) | -- Imported from Data.Typeable |instance [overlap ok] (Typeable a, Typeable b) = | Typeable (Common.Lib.Graph.Gr a b) | -- Defined at Common/ATerm/ConvInstances.hs:26:0 | In the instance declaration for `ShATermConvertible | (Common.Lib.Graph.Gr a | |b)' ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: object code blow up by optimization
Just to let you know, I can reproduce this problem nicely (thank you for
setting up the repro case). It turns out to be caused by the
simplifier's inlining policy which goes if not exponential then
something very like it. It's made dramatically worse by the fact that
$$ and + are left-associative. If you change them to right-assoc the
problem disappears I think.
That's not an excuse -- the simplifier should not do this -- but it
might be a useful workaround.
Simon
| -Original Message-
| From: Christian Maeder [mailto:[EMAIL PROTECTED]
| Sent: 10 January 2006 17:57
| To: Simon Peyton-Jones; glasgow-haskell-bugs@haskell.org
| Subject: Re: object code blow up by optimization
|
| Hi,
|
| we generate a couple of source files with orphaned instances for the
| classes Typeable and ShATermConvertible.
|
| Only adding {-# OPTIONS -O0 #-} made my code bloat problem go away
(for
| the time being).
|
| Avoiding some class methods (with mere default definitions) made the
| object code (and .hc files) only blow up half as much.
|
| -fno-strictness also kept many object files small until one module
(that
| imported all the instances) really exploded.
|
| I give up now on this matter.
|
| Cheers Christian
|
|
| Christian Maeder wrote:
| Christian Maeder wrote:
| I've a few files that produce ten times bigger .o files when
| compiled with optimization (-O). This blow-up prevents linking on
a
| mac.
|
| I had some success by adding
|
| {-# OPTIONS -fno-strictness #-}
|
| This option did finally not help.
|
| The code bloat may have something to do with unfolding (or other
| optimizations) within method instances.
|
| We have about 400 data types with (partly overlapping) Typeable and
| ShATermConvertible instances. I now changed a member function with a
| default definition to a global function and the binaries became
smaller.
|
| I could not investigate the problem any further, yet.
|
| Cheers Christian
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: panic
It's another example of the fact that the Template Haskell data type
does not support all GHC's extensions. (It started as Haskell 98, but
has various extensions beyond that.)
In this case the extension you are using is the idea that a pattern type
signature can bring a new scoped type variable into scope.
let (_ :: b) = ...
TH doesn't understand this, so it's complaining that the 'b' is not in
scope.
I'll improve the error message. Better yet would be to make TH have
scoped type variables too... but the exact design of scoped type
variables is still in flux, so I'd suggest working around it some other
way.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Frederik Eaton
| Sent: 16 December 2005 21:54
| To: glasgow-haskell-bugs@haskell.org
| Subject: panic
|
| $ ghc --make Vector.hs -fth
| Chasing modules from: Vector.hs
| [1 of 2] Skipping Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o )
| [2 of 2] Compiling Fu.Vector( Vector.hs, Vector.o )
| ghc-6.5.20051208: panic! (the `impossible' happened, GHC version
6.5.20051208):
| Failed binder lookup: b{tv a1hL}
|
| Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bug in cvs head ghci
Strange. This does not happen for me on Linux or Windows (GHc 6.4.1). Has anyone else seen it? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of wld | Sent: 08 December 2005 13:25 | To: glasgow-haskell-bugs@haskell.org | Subject: Bug in cvs head ghci | | HI, | | Typing |Prelude :b GHC.Base | | I get | [snip] | data Addr# | data Array# a | data Bool = False | True | data ByteArray# | data Char# | data Char = C# Char# | data Double# | data Float#*** Exception: No match in record selector TyCon.tyConTyVars | Prelude | | ghc built on Linux with | - ghc 6.4.1 | - gcc 4.0.2 | | -- | V.Rudenko ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: smart recompilation checker fails when only TH functions is imported
Quite correct, and thank you for pointing it out. I have known about this bug for some time. I've turned it into a sourceforge bug so we don't forget it. But it's a bit awkward to see how to fix it, so I'm probably not going to do much about it unless more people yell! (Submit follow-ups to the sourceforge bug) https://sourceforge.net/tracker/index.php?func=detailaid=1362711group_ id=8032atid=108032 Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Bulat Ziganshin | Sent: 16 November 2005 17:20 | To: glasgow-haskell-bugs@haskell.org | Subject: smart recompilation checker fails when only TH functions is imported | | Hello glasgow-haskell-bugs, | | the following scenario reproduces this error: | | 1) create Main.hs containing code | | module Main where | import Sub | main = print $x | | and Sub.hs containing code | | module Sub where | x = [| 1 |] | | | | 2) compile them with --make: | | C:\!\Haskell\!ghc --make -fth Main.hs | Chasing modules from: Main.hs | Compiling Sub ( ./Sub.hs, ./Sub.o ) | Compiling Main ( Main.hs, Main.o ) | Loading package base-1.0 ... linking ... done. | Loading package haskell98-1.0 ... linking ... done. | Loading package template-haskell-1.0 ... linking ... done. | Linking ... | | C:\!\Haskell\!main.exe | 1 | | | 3) now change Sub.hs to the following code: | | module Sub where | x = [| 2 |] | | | | 4) and recompile program: | | C:\!\Haskell\!ghc --make -fth Main.hs | Chasing modules from: Main.hs | Compiling Sub ( ./Sub.hs, ./Sub.o ) | Skipping Main ( Main.hs, Main.o ) | Linking ... | | C:\!\Haskell\!main.exe | 1 | | | As you see, Main.hs is not recompiled despite the fact that definition | of x is changed and now program must print 2 | | -- | Best regards, | Bulat mailto:[EMAIL PROTECTED] | | | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: newtype and existentials
true. GHC's intermediate language has first-class universal quantification, but not first-class existentials. I can't claim that is the Right Thing, but it might explain why GHC at least makes the choices it does Simon | -Original Message- | From: Ross Paterson [mailto:[EMAIL PROTECTED] | Sent: 18 November 2005 13:44 | To: Simon Peyton-Jones | Cc: Ralf Hinze; glasgow-haskell-bugs@haskell.org | Subject: Re: newtype and existentials | | On Fri, Nov 18, 2005 at 01:31:46PM -, Simon Peyton-Jones wrote: | yes. a newtype declares a new type isomorphic to an existing type. | newtype T = MkT S | declares T to be isomorphic to S. | | There is no existing Haskell type isomorphic to your Dynamic. | | In concrete terms, the newtype constructor is discarded before we get to | System F; but we can't do that with an existential. | | The first argument, but not the second, also applies to | | newtype T = MkT (forall a. S) ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: panic! (the `impossible' happened): Prelude.head: empty list
Thanks! I've fixed this, and added a test. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Ian Lynagh | Sent: 14 October 2005 20:51 | To: glasgow-haskell-bugs@haskell.org | Subject: panic! (the `impossible' happened): Prelude.head: empty list | | | When I try to compile this module: | | --- | module Q where | | data FooBar a b = Foo | Bar | | data P a b = P0 | P1 (FooBar a b) | | data PS p a c where | (:=) :: p a b - p b c - PS p a c | | f :: PS P a c - Int | f ((P1 _ :: P a b) := (P0 :: P b c)) = undefined | f ((P1 Bar :: P a b):= (P1 Bar :: P b c)) = undefined | f (P1 (_ :: FooBar a b) := P1 (Bar :: FooBar b c)) = undefined | --- | | I get this panic from ghc 6.4.1: | | $ ghc -fglasgow-exts -c Q.hs | ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): | Prelude.head: empty list | | Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, | or http://sourceforge.net/projects/ghc/. | | $ | | | Thanks | Ian | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
FW: ghc on macos
Can anyone help Bob with getting GHC to work on his Mac? Wolfgang? Simon -Original Message- From: Robert Harper [mailto:[EMAIL PROTECTED] Sent: 06 October 2005 00:48 To: Simon Peyton-Jones Subject: ghc on macos hi simon, today i downloaded ghc using darwinports on my macos notebook. installing ghc never terminates, unfortunately. it gets to building ghc with target all and never finishes (this after a sudo port install ghc command to the shell). bob ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GADT: weird error message
Yes, GHC has a special rule to handle case-of-expression. (We call it smart-app in the paper.) But GHC's front end retains all syntax, including tuple syntax, and I failed to do the special rule for tuple syntax. Sorry! Perhaps you can file it as a Sourceforge bug. I'm going to do a raft of changes to GADTs in the autumn, and by filing it you'll ensure I don't forget. BTW, what are you using GADTs for? Any other unexpected surprises? Thanks Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Arthur Baars | Sent: 06 September 2005 16:48 | To: glasgow-haskell-bugs@haskell.org | Subject: GADT: weird error message | | In the code below the function trans is accepted by GHC 6.4, but | trans1 is not. I would expect that (x,y) is just syntactic sugar | for (,) x y, but apparently it isn't. I guess this is a bug; can | anyone explain what is going on? | | Cheers, | | Arthur | | The Code: | data Equal a b where | Eq :: Equal a a | | trans :: forall a b c. Equal a b - Equal b c - Equal a c | trans = \x - \y - case (,) x y of | (Eq,Eq ) - Eq | | trans1 :: forall a b c. Equal a b - Equal b c - Equal a c | trans1 = \x - \y - case (x, y) of | (Eq,Eq ) - Eq | | The error message: | Test2.hs:9:0: | Quantified type variable `c' is unified with another quantified | type variable a | When trying to generalise the type inferred for `trans1' |Signature type: forall a b c. Equal a b - Equal b c - Equal | a c |Type to generalise: Equal a b - Equal b a - Equal a a | In the type signature for `trans1' | When generalising the type(s) for `trans1' | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: panic while compiling with GHC-6.4
thank you. Happily, this is already fixed; the fix will be in 6.4.1
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Dmitry Vyal
| Sent: 01 September 2005 16:45
| To: glasgow-haskell-bugs@haskell.org
| Subject: panic while compiling with GHC-6.4
|
| this code snippet makes GHC-6.4 and GHCI-6.4 panic:
|
| data DL a = DL {prev_dl::DL, el::a, next_dl::DL}
|
| go :: DL a - [a] - DL a - (DL a,DL a)
| go prev [] next = (prev, next)
| go prev (x:xs) next = let this = DL prev x rest
|(rest,fin) = go this xs next
|in this
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: scavenge_one: strange object 47
Can you give more info? Specifically, what version of GHC? What flags? What platform? Perhaps you can file a bug at Sourceforge http://sourceforge.net/bugs/?group_id=8032 giving this info? Do include your sources as a download too. thanks Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] | Sent: 30 August 2005 17:12 | To: glasgow-haskell-bugs@haskell.org; [EMAIL PROTECTED] | Subject: scavenge_one: strange object 47 | | | Hi, i hope this is a bug. | | Please look at the file Mult.hs | | and function: startM1 (17-20) | | run this function for different inputs (orignially, multiply (1%7) with | (0%2)) try to run with : (1%3) and (0%1) |(2%3) and (0%1) |(1%2) and (0%1) |(1%5) and (0%1) | | | Best regards | TuanAnh ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: --make and -main-is still not working together?
Ah I see now. The underlying problem is that GHC's no need to recompile check takes account of changes in the source file, but does not take into account changes in the flags. So it skipped recompiling Test2, but it should have recompiled it to make the -main-is take effect. Failing to do so gives a bad error message, as you found. I've filed a sourceforge bug, but I doubt we'll get to it quickly. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Niels | Sent: 11 August 2005 09:29 | To: glasgow-haskell-bugs@haskell.org | Subject: Re: --make and -main-is still not working together? | | I can't reproduce this failure: | | ~/scratch cat ModName/Main.hs | module ModName.Main where | main=print hello | ~/scratch ghc -o out --make ModName/Main.hs -main-is ModName.Main.main | Chasing modules from: ModName/Main.hs | Skipping ModName.Main ( ModName/Main.hs, ModName/Main.o ) | Linking ... | | This is 6.4 on x86/Linux. Is there anything I'm missing? | | Actually, i reproduced it now and the reason is a bit different. I have an | application Test and Test2. They both have a main function. Test imports Test2 | for some other function. So this is how those files look like: | | ~/pancake cat Test.hs | module Test where | import Test2 hiding (main) | | main = doit | | ~/pancake cat Test2.hs | module Test2 where | | doit = print Test2.doit | main = print Test2.main | | I then first compile the first app: | ~/pancake ghc --make -main-is Test.main Test.hs | Chasing modules from: Test.hs | Compiling Test2( ./Test2.hs, ./Test2.o ) | Compiling Test ( Test.hs, Test.o ) | Linking ... | | then i compile the second app: | ~/pancake ghc --make -main-is Test2.main Test2.hs | Chasing modules from: Test2.hs | Skipping Test2( Test2.hs, Test2.o ) | Linking ... | /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main': | : undefined reference to `__stginit_ZCMain' | /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In function `main': | : undefined reference to `ZCMain_main_closure' | collect2: ld returned 1 exit status | | So I guess generating Test2.o the first time and using -main-is renamed the main | in Test2.o . Since it is not recompiled when I want to compile the second app, | it fails because it cant find the main...I thought providing a -main-is flag | again when compiling the second app would somehow force recompilation of Test2.o | or at least fixing the 'renaming' that the first compilation of Test2.o had | caused. | | greetings, Niels. | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
Yes, you could I suppose. But then there'd be a different peculiar change in behaviour at arity 7. I'm not sure that'd be an advantage. Simon | -Original Message- | From: Simon Marlow | Sent: 10 August 2005 10:58 | To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org | Subject: RE: Deriving Typeable instances | | On 09 August 2005 17:16, Simon Peyton-Jones wrote: | | I'm not against this, although you can work around the problem by | adding a library that defines the missing type classes (Typeable8, | Typeable9 etc), and making your compiler generate the instance | itself. There is nothing magic about 'deriving'; it's just | convenient. | | If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? | It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. | | Cheers, | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
| data T a b c d e f g h = T a b c d e f g h | deriving Typeable | | fails in ghc-6.4 with the message: | Can't make a derived instance of `Typeable (T a b c d e f g h)' | (`T' has too many arguments) | When deriving instances for type `T' | | In ghc 6.2.2, it was no problem to derive Typeable instances for type | constructors of higher (arbitrary?) arities. Yes, this was a change, I'm afraid, and not a documented one. I've updated the documentation (see below for the diff, and the explanation). | If it is not possible to provide deriving Typeable for arbitrary arity | of type constructors anymore, would it be possible to extend deriving to | at least type constructors of arity 20? We are using Haskell as a target | language of a compiler and here type constructors with many arguments occur. I'm not against this, although you can work around the problem by adding a library that defines the missing type classes (Typeable8, Typeable9 etc), and making your compiler generate the instance itself. There is nothing magic about 'deriving'; it's just convenient. The Read and Show instances for tuples go up to arity 15, and since we have some arbitrary numbers in GHC we might as well have as few as possible. So would arity 15 do? If you really want 20 maybe we should do the same for Read/Show on tuples. If someone likes to volunteer to do the actual work on the library Data.Typeable, I think we could adopt it. It's simple but boring to follow the recipe for Typable1..Typeable7. I'm a bit tied up right now. Simon + paraAn instance of literalTypeable/literal can only be derived if the + data type has seven or fewer type parameters, all of kind literal*/literal. + The reason for this is that the literalTypeable/literal class is derived using the scheme + described in + ulink url=http://research.microsoft.com/%7Esimonpj/papers/hmap/gmap2.ps; + Scrap More Boilerplate: Reflection, Zips, and Generalised Casts + /ulink. + (Section 7.4 of the paper describes the multiple literalTypeable/literal classes that + are used, and only literalTypeable1/literal up to + literalTypeable7/literal are provided in the library.) + In other cases, there is nothing to stop the programmer writing a literalTypableX/literal + class, whose kind suits that of the data type constructor, and + then writing the data type instance by hand. + /para | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frank Huch | Sent: 04 August 2005 18:00 | To: glasgow-haskell-bugs@haskell.org | Subject: Deriving Typeable instances | | Hi, | | we have a problem with deriving Typeable instances in ghc-6.4. The | following code | | data T a b c d e f g h = T a b c d e f g h | deriving Typeable | | fails in ghc-6.4 with the message: | Can't make a derived instance of `Typeable (T a b c d e f g h)' | (`T' has too many arguments) | When deriving instances for type `T' | | In ghc 6.2.2, it was no problem to derive Typeable instances for type | constructors of higher (arbitrary?) arities. | | If it is not possible to provide deriving Typeable for arbitrary arity | of type constructors anymore, would it be possible to extend deriving to | at least type constructors of arity 20? We are using Haskell as a target | language of a compiler and here type constructors with many arguments occur. | | Regards, | Frank | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell-cafe] Control.Monad.Cont fun
Ah I see. This is really a bug. GHC6.4 should accept the example. I've just fixed it. thanks for mentioning it. Simon | -Original Message- | From: Thomas Jäger [mailto:[EMAIL PROTECTED] | Sent: 26 July 2005 13:38 | To: Simon Peyton-Jones | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: [Haskell-cafe] Control.Monad.Cont fun | | Basically, the pre-ghc6.4 way of doing scoped type variables breaks | down for higher-rank functions. For example | | foo :: (forall a. a - b) - b | foo (f :: forall a. a - b) = f undefined :: b | | is accepted by ghc-6.2 but rejected by the current ghc with an error message | Couldn't match `forall a. a - b' against `forall a. a - b' | | Of course, in ghc-6.4 we don't need f's type annotation so this will work fine: | | bar :: forall b. (forall a. a - b) - b | bar f = f undefined :: b | | But I'm not aware of anything that will work simulateously for both versions. | | Thomas | | On 7/26/05, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | Andrew, Thomas | | Can you send me a self-contained module that elicits the mysterious message (I agree that it is a | strange one)?Can you also include the variant that does work. | | Then I'll look into it. | | Thanks | | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bug in The Glorious Glasgow Haskell Compilation System User's Guide, Version 6.4
Quite right. The documentation should say Q Exp instead of Expr. Ill fix that. (ExpQ is a synonym for Q Exp) Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen Brown Sent: 24 July 2005 02:08 To: glasgow-haskell-bugs@haskell.org Subject: Bug in The Glorious Glasgow Haskell Compilation System User's Guide,Version 6.4 Section 7.6.1 reads: _expression_ quotation is written in Oxford brackets, thus: o [| ... |], where the ... is an _expression_; the quotation has type Expr. On the other hand GHCi 6.4behaves as follows: Prelude V02pIL :type [|foo|] [|foo|] :: Language.Haskell.TH.Lib.ExpQ Hence it appears that the implementation does not agree with the documentation as to what might be the type of a quasi-quoted _expression_. Allen L. Brown, Jr., Ph.D. Senior Software Architect Bigtop Team Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA +1 425 705-3290 (voice) +1 425 985-8961 (mobile) +1 425 706-7329 (fax) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] (email) ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Recompiling doesn't notice re-exports being removed
How true. A long-standing bug, thank you. Now fixed. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Ian Lynagh | Sent: 19 July 2005 23:24 | To: glasgow-haskell-bugs@haskell.org | Subject: Recompiling doesn't notice re-exports being removed | | | Recompiling doesn't notice re-exports being removed: | | | $ cat A.hs | | module A where | | foo :: Int | foo = 4 | | $ cat B.hs | | module B (foo) where | | import A (foo) | | $ cat C.hs | | module Main (main) where | | import B (foo) | | main :: IO () | main = print foo | | $ ghc --make C -o c | Chasing modules from: C | Compiling A( ./A.hs, ./A.o ) | Compiling B( ./B.hs, ./B.o ) | Compiling Main ( C.hs, C.o ) | Linking ... | $ sed -i s/foo// B.hs | $ cat B.hs | | module B () where | | import A () | | $ ghc --make C -o c | Chasing modules from: C | Skipping A( ./A.hs, ./A.o ) | Compiling B( ./B.hs, ./B.o ) | Skipping Main ( C.hs, C.o ) | Linking ... | $ # compilation above should have failed, as below | $ rm *.o *.hi c | $ ghc --make C -o c | Chasing modules from: C | Compiling A( ./A.hs, ./A.o ) | Compiling B( ./B.hs, ./B.o ) | Compiling Main ( C.hs, C.o ) | | C.hs:4:10: Module `B' does not export `foo' | $ | | | Thanks | Ian | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: make fail for 6.4.1-pre-July-11
I think you may have caught GHC just after a bogus change was merged. It was fixed a few minutes later. Try now. SImon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Serge D. Mechveliani | Sent: 11 July 2005 13:14 | To: glasgow-haskell-bugs@haskell.org | Subject: make fail for 6.4.1-pre-July-11 | | It still cannot make. | I have downloaded ghc-6.4.1-pre of CVS July 11 2005 | | (this is the date of the act of downloading) | | and am trying to make it with ghc-6.4.1-pre of June 15 | under Debian Linux. | It reports | | - | ... | ... | /home/mechvel/ghc/cvs/instJune14/bin/ghc -H16m -O -istage1/utils | -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude | -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn | -istage1/specialise -istage1/simplCore -istage1/stranal | -istage1/stgSyn -istage1/simplStg -istage1/c\odeGen -istage1/main | -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/compMan | -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen | -istage1/ghci -Istage1 -DGHCI -package template-haskell -package ... | ... | ... | rename/RnExpr.lhs:85:4: | Couldn't match `IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars)' against | `t - \t1' | Expected type: IOEnv (Env TcGblEnv TcLclEnv) (a, FreeVars) | Inferred type: t - t1 | Expected type: a1 - b | Inferred type: RnM (a, FreeVars) | Probable cause: | `rnPatsAndThen' is applied to too many arguments in the call | (rnPatsAndThen ctxt True pats) | ghc: 76871052 bytes, 21 GCs, 4067284/8625320 avg/max bytes residency | (4 sampl\es), 19M in use, 0.02 INIT (0.00 elapsed), 0.97 MUT | (1.10 elapsed), 0.90 GC (0.\90 elapsed) :ghc | make[2]: *** [stage1/rename/RnExpr.o] Error 1 | make[1]: *** [all] Error 1 | make[1]: Leaving directory `/home/mechvel/ghc/cvs/pre6.4.1/fptools/ghc' | make: *** [build] Error 1 | --- | | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Compiling ghc 6.4 with ghc 5.04.3
That's weird. We compile 6.4 with 5.04.3 every night. Maybe you are using different flags than we are? - can you send your build.mk - plus a full transcript so we can see what flags are being passed to ghc (e.g. -O2) Is your source tree for 6.4 - the STABLE branch, or - the exact bits for 6.4 downloaded from the download site? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Axel Simon | Sent: 06 July 2005 09:14 | To: glasgow-haskell-bugs@haskell.org | Subject: Compiling ghc 6.4 with ghc 5.04.3 | | Hi, | | I'm trying to bootstrap 6.4 with a binary 5.04.3 on Debian Linux. | | I get the following during linking: | | stage1/nativeGen/AsmCodeGen.o: In function `slZu_dflt': | stage1/nativeGen/AsmCodeGen.o(.text+0x7ebe): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slZB_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x7ffc): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slZD_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x8004): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slAj_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x82bc): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slZL_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x82c4): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o(.text+0xb0bc): more undefined references | to `GHCziPrim_zdwZ2H_entry' follow | collect2: ld returned 1 exit status | ghc: 4414788 bytes, 2 GCs, 155432/155432 avg/max bytes residency (1 | samples), 5M in use, 0.01 INIT (0.00 elapsed), 0.01 MUT (10.98 elapsed), | 0.02 GC (0.02 elapsed) :ghc | make[2]: *** [stage1/ghc-6.4] Error 1 | make[1]: *** [all] Error 1 | make[1]: Leaving directory | `/home/part3/cur/as49/gonzo/source/ghc-6.4/ghc' | make: *** [build] Error 1 | | Can anyone tell me | | a) if 6.4 is supposed to compile with 5.04.3. | b) if not, via what other version can I get from 5.04.3 to 6.4. | c) if there is a newer binary package of ghc that works with glibc 2.2 | | Thanks, | Axel. | | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghci obscurity
That's strange, if you are using the HEAD. I get Prelude Data.Generics (\x - case cast x of Just x'@(a,b) - print x'; Nothing - putStrLn No match) (2::Int,3::Int) No match Incidentally, the 'no match' is because you aren't fixing the type of 'a' and 'b', so they are ambiguous and are defaulted to (Integer,Integer). Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 24 May 2005 10:19 | To: Simon Peyton-Jones | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: ghci obscurity | | Thank you! | | I imagine that if you think you've fixed it then you have, but here's | an example: | | Prelude Data.Generics (\x - case cast x of Just x'@(a,b) - print x'; Nothing - putStrLn No | match) (2::Int,3::Int) | | Top level: | No instance for (Show (IO ())) | arising from use of `print' at Top level | Probable fix: add an instance declaration for (Show (IO ())) | In a 'do' expression: print it | | I think the real error is that (,) is missing an instance... | | Frederik ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghci obscurity
Good point Happily, I improved this error message (which has been in SourceForge for some time) last Friday. At least I hope so; you didn't actually give an example. If you do, I'll try it. Or check out the HEAD and see if things have improved. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 21 May 2005 14:34 | To: glasgow-haskell-bugs@haskell.org | Subject: ghci obscurity | | Often ghci will give me the following message instead of something | helpful: | | Top level: | No instance for (Show (IO ())) | arising from use of `print' at Top level | Probable fix: add an instance declaration for (Show (IO ())) | In a 'do' expression: print it | | I don't know how hard it would be to fix, but it's kind of a nuisance. | It seems to only come up when something else is wrong, but it often | comes up *instead* of a good error message for the real problem, | making it very hard to track the real problem down. | | Frederik | | -- | http://ofb.net/~frederik/ | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: the impossible happened
This fromJust bug is SourceForge 1177320. The trouble is that we've been unable to reproduce it here. It seems to show up when compiling some large thing, like Darcs or WASH. If anyone would be willing to snapshot a tree exhibiting the bug, and send it to us, we'd love to investigate. Until then we're a bit stuck. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 21 May 2005 11:49 | To: glasgow-haskell-bugs@haskell.org | Subject: the impossible happened | | ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): | Maybe.fromJust: Nothing | | Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, | or http://sourceforge.net/projects/ghc/. | | I think this was the command line: | | /home/frederik/arch/i386/bin/ghc -odir dist/build/../webpage.cgi-tmp -hidir dist/build/../webpage.cgi- | tmp -o dist/build/../webpage.cgi --make -i.. -O3 -fignore-asserts -fglasgow-exts -package base-1.0 - | package posix-1.0 -package haskell98-1.0 -package WASH-CGI -package WASHHTML | ../maint/webpage.hs -v | | Frederik | | -- | http://ofb.net/~frederik/ | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: the impossible happened
I believe that the problem here is that the Wash distribution isn't
right for GHC 6.4; in particular, the package-specification format
changed a bit. Wash needs to be updated.
Sorry about this -- the packaging story for Haskell is still in flux,
and that means that old packages won't necessarily compile with new
compilers.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Frederik Eaton
| Sent: 17 May 2005 07:12
| To: glasgow-haskell-bugs@haskell.org
| Subject: the impossible happened
|
| /home/frederik/arch/i386/bin/ghc -odir dist/build/../pp-web.cgi-tmp
-hidir dist/build/../pp-web.cgi-
| tmp -o dist/build/../pp-web.cgi --make -i.. -O3 -fignore-asserts
-fglasgow-exts -package base-1.0 -
| package WASH-CGI ../maint/webpage.hs -v
| Glasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC
version 5.04.3
| Using package config file:
/home/frederik/arch/i386/lib/ghc-6.4/package.conf
| Using package config file:
/home/frederik/.ghc/i386-linux-6.4/package.conf
| Hsc static flags: -static
| *** Chasing dependencies:
| Chasing modules from: ../maint/webpage.hs
| Stable modules:
| *** Compiling Main ( ../maint/webpage.hs, interpreted ):
| compile: input file ../maint/webpage.hs
| *** Checking old interface for Main:
| Compiling Main ( ../maint/webpage.hs,
dist/build/../pp-web.cgi-tmp/Main.o )
| *** Parser:
| *** Renamer/typechecker:
|
/home/frederik/arch/i386/lib/WASH-CGI-1.4.37/ghc-6-4/import/CGIInternals
.hi :
| Could not find module `HTMLMonadBase':
| it is not a module in the current program, or in any known
package.
| *** Deleting temp files
| Deleting: /tmp/ghc14692.hc
| Warning: deleting non-existent /tmp/ghc14692.hc
| ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
| forkM Declaration for standardQuery{v}
|
| Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
|
| --
| http://ofb.net/~frederik/
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Unused variable warnings when deriving (Data)
Good point. I've fixed this.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Tomasz Zielonka
| Sent: 27 April 2005 10:09
| To: GHC-bugs
| Subject: Unused variable warnings when deriving (Data)
|
| Hello!
|
| When I compile the following module with ghc -W -c A.hs I see
several
| unnecessary warning messages:
|
| $ ghc --version
| The Glorious Glasgow Haskell Compilation System, version 6.4
| $ ghc -no-recomp -W -c A.hs
|
| no location info: Warning: Defined but not used: `k'
|
| no location info: Warning: Defined but not used: `k'
|
| no location info: Warning: Defined but not used: `k'
|
| Adding parameters to data constructors makes the warnings disappear,
| example:
| data T = A Int | B Char
|
| A.hs ---
|
| {-# OPTIONS -fglasgow-exts #-}
|
| module A where
|
| import Data.Generics
|
| data T = A | B
| deriving (Typeable, Data)
|
| -
|
| Best regards
| Tomasz
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc.exe: panic! (the `impossible' happened, GHC version 6.4)
Thanks for the report. You're using a class as a type (in the data type
decl for ScreenStack) and this triggers a bug in 6.4. It been fixed,
and the fix will be in 6.4.1.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Damyan Pepper
| Sent: 24 April 2005 10:29
| To: glasgow-haskell-bugs@haskell.org
| Subject: ghc.exe: panic! (the `impossible' happened, GHC version 6.4)
|
| The compiler has asked me to send a bug report...so here it is. This
| is with the Windows distribution of GHC 6.4.
|
| Compiling the following code:
|
| import Graphics.UI.ObjectIO hiding (Menu)
|
| class CScreen a where
| updateScreen :: a - a
| drawScreen :: a - Draw ()
|
| data ScreenStack e l = EmptyScreenStack | ScreenStack (CScreen e) l
|
|
| Produces the following message:
|
| ghc -package objectio t.hs
| ghc.exe: panic! (the `impossible' happened, GHC version 6.4):
| ds_app_type Main.CScreen{tc r1TC} [e{tv a1V4}]
|
| Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
|
|
| I expect the code isn't correct, but I guess the compiler should give
| a sensible error messge.
|
| Thanks,
| Damyan.
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: cvs head, winxp, make fails to make target `HSwin32.o', needed by `all'.
Good point. I'll fix the documentation. hslibs are deprecated, and not required for building GHC. (But they should still build) Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Claus Reinke | Sent: 14 April 2005 18:00 | To: Simon Peyton-Jones; glasgow-haskell-bugs@haskell.org | Subject: Re: cvs head, winxp, make fails to make target `HSwin32.o',needed by `all'. | | | I'm trying to build todays cvs ghc on a winxp box, without trying | | anything unusual. The build fails and I am rather lost in the | | makefiles - any suggestions? | | I have not build hslibs/ myself for a long time. Is there some reason | you want to? | | none at all - just followed the building guide. section 2.2, for checkout, | which probably leads to it being compiled later because its there? | | http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html#cvs-fi rst | | cheers, | claus | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bus Error with ghc 6.4 on Solaris
Simon M is away today and Monday, but I do recall him saying something about the Solaris port being broken. I'm sure he would welcome help getting it fixed. Are there any of you who build GHC from source, and know Solaris? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Christian Maeder | Sent: 15 April 2005 12:36 | To: Martin Preen | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Bus Error with ghc 6.4 on Solaris | | These bus errors are the reason for a missing ghc-6.4 solaris distribution. | | Is someone able to investigate such bus errors? | | Cheers Christian | | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: cvs head, winxp, make fails to make target `HSwin32.o', needed by `all'.
| I'm trying to build todays cvs ghc on a winxp box, without trying | anything unusual. The build fails and I am rather lost in the | makefiles - any suggestions? | | Cheers, | Claus | | | $ autoreconf | $ ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc | $ make 21 | tee make.log | | the last segments of make.log: | | .. | | | ===fptools== Finished recursively making `all' for ways: p ... | PWD = /cygdrive/c/fptools/fptools/hslibs/hssource | | | ==fptools== make all - --unix -wr; | in /cygdrive/c/fptools/fptools/hslibs/win32 | | I have not build hslibs/ myself for a long time. Is there some reason you want to? Can anyone else help Claus? Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC 6.4/mingw32: files larger than 4 GB andhFileSize/hSetFileSize/c_stat
By all means. If someone cares to send us a patch, we'll incorporate it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Bulat Ziganshin | Sent: 08 April 2005 10:38 | To: glasgow-haskell-bugs@haskell.org | Subject: GHC 6.4/mingw32: files larger than 4 GB andhFileSize/hSetFileSize/c_stat | | | While GHC I/O library on mingw32 platform perfectly reads and writes | files larger than 4 GB, functions hFileSize/c_fstat, | hSetFileSize/c_ftruncate and c_stat are still tied to C functions | returning 32 bit values and as a result truncate larger sizes to their | low 32 bits. Can this behaviour be fixed in the next bug-fix version? | | | -- | Best regards, | Bulat mailto:[EMAIL PROTECTED] | | | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Repeated :info giving different results
The trouble is that instance declarations could be in *any* module. So at the moment GHC just reports the instances it knows about. As time goes on, it knows about more modules, so it may report more instances. I agree that it's odd that simply reporting one lot makes it know about more! And I don't claim that this is desirable behaviour. It'd be better if you saw all the instance declarations that can be written in the current scope using unqualified names. I'll file this as a bug. Yell if it's hurting you; otherwise it'll be low priority. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Remi Turk | Sent: 19 March 2005 23:22 | To: glasgow-haskell-bugs@haskell.org | Subject: Repeated :info giving different results | | Hi, | | every once in a while, a screenshot says more than a thousand words. | And it's global: :i Bool followed by :i Int shows exactly | the same symptom. | | Groeten, | Remi | | | ~% ghci |___ ___ _ | / _ \ /\ /\/ __(_) | / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. | / /_\\/ __ / /___| | http://www.haskell.org/ghc/ | \/\/ /_/\/|_| Type :? for help. | | Loading package base-1.0 ... linking ... done. | | Prelude :i Bool | data Bool = False | True -- wired into compiler | instance Eq Bool -- Imported from GHC.Base | instance Ord Bool -- Imported from GHC.Base | | Prelude :i Bool | data Bool = False | True -- wired into compiler | instance Bounded Bool -- Imported from GHC.Enum | instance Enum Bool-- Imported from GHC.Enum | instance Eq Bool -- Imported from GHC.Base | instance Ord Bool -- Imported from GHC.Base | instance Read Bool-- Imported from GHC.Read | instance Show Bool-- Imported from GHC.Show | | Prelude | | -- | Nobody can be exactly like me. Even I have trouble doing it. | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: --make and -make-is
Yes; same issue. I've added a note to the documentation of -main-is: existing stuff Strictly speaking, option-main-is/option is not a link-phase flag at all; it has no effect on the link step. The flag must be specified when compiling the module containing the specified main function (e.g. module literalA/literal in the latter two items above). It has no effect for other modules, and hence can safely be given to literalghc --make/literal. new stuff starts here: However, if all the modules are otherwise up to date, you may need to force recompilation both of the module where the new main is, and of the module where the main function used to be; literalghc/literal is not clever enough to figure out that they both need recompiling. You can force recompilation by removing the object file, or by using the option-no-recomp/option flag. | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Kristofer Johannisson | Sent: 17 March 2005 22:58 | To: glasgow-haskell-bugs@haskell.org | Subject: --make and -make-is | | Running GHC 6.4 on Mac OS X 10.3.8. | | I have problems using --make and -make-is, which seem to be related to | bug [ 935792 ] --make and -main-is don't work together. The shell | transcript below illustrates the problem. | | / Kristofer Johannisson | | | | prompt$ ls | A.hs | prompt$ more A.hs | module A where | | main = putStrLn hello world | | prompt$ ghc --make A.hs | Chasing modules from: A.hs | Compiling A( A.hs, A.o ) | prompt$ ls | A.hiA.hsA.o | prompt$ ghc -main-is A --make A.hs | Chasing modules from: A.hs | Skipping A( A.hs, A.o ) | Linking ... | ld: Undefined symbols: | _ZCMain_main_closure | ___stginit_ZCMain | prompt$ rm -f A.o | prompt$ ghc -main-is A --make A.hs | Chasing modules from: A.hs | Compiling A( A.hs, A.o ) | Linking ... | prompt$ ./a.out | hello world | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bad eta expand during building
don't worry abou thtem. I keep meaning to look into it again, but it's
harmless I think. Certainly long standing
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Axel Simon
| Sent: 16 March 2005 13:44
| To: glasgow-haskell-bugs@haskell.org
| Subject: Bad eta expand during building
|
| Hi,
|
| I'm just trying to compile ghc 6.4. I was a bit put off by ton's of
Bad
| eta expand messages scrolling off my screen. It looks like this:
|
| Bad eta expand
| 1
| __coerce GHCziBase.Z0T{(w) tc 40}
| (CmmParse.zgzg{v rej3}
|@ GHCziBase.Z0T{(w) tc 40}
|@ GHCziBase.Z0T{(w) tc 40}
|(__coerce CmmParse.ExtCode{tc r3CA} happyzuxzu1{v a3WU})
|(__coerce CmmParse.ExtCode{tc r3CA} happyzuxzu2{v a3WT})
|(__coerce CmmParse.Env{tc r3CI} eta{v sb4W}))
| GHCziBase.Z0T{(w) tc 40}
| ghc: 1194327916 bytes, 3628 GCs, 13332977/21631780 avg/max bytes
| residency (11 samples), 57M in use, 0.00 INIT (0.00 elapsed), 5.13 MUT
| (39.72 elapsed), 2.47 GC (2.59 elapsed) :ghc
| ../../ghc/compiler/stage1/ghc-inplace -H16m -O -istage2/utils -
| istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude
-
| istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn
| -istage2/specialise -istage2/simplCore -istage2/stranal -
| istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -
| istage2/profiling -istage2/parser -istage2/cprAnalysis -
| istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -
| istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-
| haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-
| generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix
-
| package Cabal -recomp -Rghc-timing -H16M '-#include hschooks.h'
-c
| utils/FiniteMap.lhs -o stage2/utils/FiniteMap.o -ohi
| stage2/utils/FiniteMap.hi
|
| I don't know which files this refers to as there were way too many of
| these messages to scroll back. But the next file is obviously
| FiniteMap.lhs
|
| Does this message have to scare me? And if yes, why does the build
| proceed?
|
| Axel.
|
|
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: more GADT surprises
Thanks. Both this and your earlier message are fixed in the HEAD; and tests added. Keep them coming Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Andres Loeh | Sent: 15 March 2005 13:45 | To: glasgow-haskell-bugs@haskell.org | Subject: more GADT surprises | | Surprisingly, the attached Haskell module loads successfully in ghci-6.4: | | Ok, modules loaded: Main. | *Main :t A | A :: A | *Main :t B | B :: B [] | *Main :t B' | B' :: B [Int] | *Main [B,B'] | ghc-6.4: panic! (the `impossible' happened, GHC version 6.4): | Unify.unifyTauTyLists: mismatched type lists! | | Please report it as a compiler bug to | glasgow-haskell-bugs@haskell.org, | or http://sourceforge.net/projects/ghc/. | | | Best, | Andres ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Object IO problem
Are there any Object-IO folk out there who'd like to fix (or otherwise resolve) this sourceforge bug? https://sourceforge.net/tracker/index.php?func=detailaid=1145315group_ id=8032atid=108032 Simon Problem 1: When using the ObjectIO library, setting the view domain of a compund control does not correctly adjust the min/max settings of the corresponding scroll-sliders. Problem 2: When trying to work around this bug, it turns out that you can only set the scroll function for Horizontal scrolling but not for Vertical scrolling. Do you need an example programs for the bugs? [SLPJ: yes, pls upload an example] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: impossible happened with class XML a where toXML :: a - XML
It was a bug -- thank you. Now fixed (though it missed the 6.4 boat),
and in the regression suite.
SImon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Shae Matijs Erisson
| Sent: 10 March 2005 21:13
| To: glasgow-haskell-bugs@haskell.org
| Subject: impossible happened with class XML a where toXML :: a -
XML
|
|
| Breaking code is:
| class XML a where toXML :: a - XML
|
| result is:
| Compiling Main ( /home/shae/src/haskell/ProtoWebPublish.hs,
interpreted )
| ghc-6.4.20050303: panic! (the `impossible' happened, GHC version
6.4.20050303):
| ds_app_type Main.XML{tc r1BX} []
|
| Not sure if this is already a known bug.
| --
| Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster
once said:
| You could switch out the unicycles for badgers, and the game would be
the same.
|
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Illtyped generated code with unsafeCoerce#, F# and -O
unsafeCorece is intended to be a no-op at run-time; that is, it has no work to do. Converting a pointer to one type of thing to a pointer to another type of thing is an example. Converting a 32-bit Int to a 64 bit int is *not* an example. Converting a 32-bit float to a 32-bit int (which you are trying here) may or may not be an example, I guess, depending on the architecture. Rather than trying to keep casts, I'd suggest adding a new primop for non-trivial primitive-type conversions. There might be a lot of these I suppose; we could consider making them 'polymorphic', but retaining the type in STG land. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Simon Marlow | Sent: 11 March 2005 10:20 | To: Donald Bruce Stewart; glasgow-haskell-bugs@haskell.org | Subject: RE: Illtyped generated code with unsafeCoerce#, F# and -O | | On 11 March 2005 01:45, Donald Bruce Stewart wrote: | | Hey guys, | | The following (evil, yes) program compiles and works under ghc -Onot | using -fasm or -fvia-C, but fails to generated correct code under all | GHCs back to ghc-5.04.2 if I turn on -O. (It also works under ghci). | | When working it runs and produces the following (correct) result: | | paprika$ ./a.out | .0 | (69,243,8,0) | .0 | | However, if I turn on -O it fails to generate acceptable asm or C. | | Am I right in thinking that all uses of unsafeCoerce# should never | cause type-incorrect C or asm code to be generated (no matter what | evil happens at runtime)? | | Now, -dcore-lint is fine, but our shiny new 6.4 -dcmm-lint spots the | error :) | | Cmm lint error: |in proc s2D4_ret | in basic block c2F7 |in MachOp application: | .0 :: F32 255 | | I *think* the answer is that this kind of type casting just isn't | supported by the code generator at the moment. The Core is fine because | it includes the explicit type coercion, but this has been lost in the | STG code, and the code generator assumes that it is generating code for | type-correct STG code (although some coercions are allowed, ie. | coercions between values with the same MachRep). | | I can see at least two ways we might try to fix this: | | - try to detect type incompabilities in the STG-cmm code generator |and insert type casting operations. | | - possibly retain the type coercion from Core as an application of |a type-casting operation in STG, so the backend can generate |appropriate code for it. | | The latter sounds more promising. | | Cheers, | Simon | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: retainer profiling documentation
Thanks for a constructive suggestion. We've incorporated your rewording. I'll take this opportunity to encourage GHC users to offer suggested rewording or clarifications to GHC's documentation. We're far more likely to do something if you suggest an improvement in concrete terms, rather than simply say this should be better documented (which is almost invariably true!). And you're also in a much better position to write clear documentation from the point of view of a user, than we are as implementers. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 09 March 2005 20:43 | To: glasgow-haskell-bugs@haskell.org | Subject: retainer profiling documentation | | I think the documentation for retainer profiling could be clearer... | | 5.4.2. Retainer Profiling | | Retainer profiling is designed to help answer questions like why is | this data being retained?. We start by defining what we mean by a | retainer: | | A retainer is either the system stack, or an unevaluated closure (thunk). | | In particular, constructors are not retainers. | | An object A is retained by an object B if object A can be reached by | recursively following pointers starting from object B but not meeting | any other retainers on the way. Each object has one or more retainers, | collectively called its retainer set. | | I'm not sure I understand this but I'll try to rephrase it in a way | which I think is easier to parse. | | 5.4.2. Retainer Profiling | | Retainer profiling is designed to help answer questions like why is | this data being retained?. We start by defining what we mean by a | retainer object: | | A retainer object is either the system stack, or an unevaluated | closure (thunk). | | In particular, constructors are not retainer objects. | | Now we define what it means for one object to retain another: | | An object B retains object A if it is a retainer object and | object A can be reached by recursively following pointers | starting from object B, but not meeting any other retainer | objects on the way. Each object is retained by one or more | retainer objects, collectively called its retainer set, or its | retainers. | | Is this OK? I'm trying to distinguish the class of objects which are | allowed to be retainers - thunks and the stack - from ones which | actually retain other objects. E.g. one could have a thunk which | doesn't retain anything, I think it's confusing to define such a thing | as a retainer, I thought retainer object would be clearer. | | Frederik | | -- | http://ofb.net/~frederik/ | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: 6.4.20050304 RULES panic from CgMonad.lhs other nastiness
Excellent bug. It's been there a long time. You seem to have a talent
for finding dark corners in GHC!
Anyway, it's fixed, and a test added.
SImon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Remi Turk
| Sent: 07 March 2005 00:41
| To: glasgow-haskell-bugs@haskell.org
| Subject: 6.4.20050304 RULES panic from CgMonad.lhs other nastiness
|
| Hi,
|
| while still trying to get Data.HashTable to work both in ST and
| IO (I'll probably start complaining about optimizations not
| performed once this is fixed ;), I bumped into the following
| nastiness.
|
| Comments interleaved with shell copy-paste-work.
|
|
|% make clean
|rm -f *.o *.hi a.out
|
|
|% /var/tmp/ghc/bin/ghc --make -O Main.hs
|Chasing modules from: Main.hs
|Compiling MHashTable ( ./MHashTable.hs, ./MHashTable.o )
|Compiling Main ( Main.hs, Main.o )
|ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
6.4.20050304):
| cgPanic
|zdfMutHashSTArray{v a1ip}
|static binds for:
|local binds for:
|SRT labelghc-6.4.20050304: panic! (the `impossible' happened,
GHC version 6.4.20050304):
| initC: srt
|
| Okay, it dies. Almost any new change in the source makes this one
| go away. The next panic is probably partly a consequence of this
| one: MHashTable.o already exists and GHC can't cope with that for
| some reason. That reason may of course be that MHashTable.o
| contains garbage due to the previous bug.
|
|
|% /var/tmp/ghc/bin/ghc --make -O Main.hs
|Chasing modules from: Main.hs
|Skipping MHashTable ( ./MHashTable.hs, ./MHashTable.o )
|ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
6.4.20050304):
| tcIfaceGlobal (local): not found:
|MHashTable.updateST{v r87}
|[(rr, Identifier `MHashTable.zdfMutHashSTArray{v rr}'),
| (rs, Type constructor `MHashTable.HT{tc rs}'),
| (rt, Identifier `MHashTable.dir{v rt}'),
| (ru, Data constructor `MHashTable.HT{d ru}'),
| (rv, Identifier `MHashTable.HT{v rv}'),
| (rw, Type constructor `MHashTable.HashTable{tc rw}'),
| (rx, Data constructor `MHashTable.HashTable{d rx}'),
| (ry, Identifier `MHashTable.zdWHashTable{v ry}'),
| (rz, Type constructor `MHashTable.STHashTable{tc rz}'),
| (rA, Class `MHashTable.MutHash{tc rA}'),
| (rB, Type constructor `MHashTable.ZCTMutHash{tc rB}'),
| (rC, Data constructor `MHashTable.ZCDMutHash{d rC}'),
| (rD, Identifier `MHashTable.ZCDMutHash{v rD}'),
| (rE, Identifier `MHashTable.newMHArray{v rE}'),
| (rF, Identifier `MHashTable.readMHArray{v rF}'),
| (rG, Identifier `MHashTable.writeMHArray{v rG}'),
| (rH, Identifier `MHashTable.newMHRef{v rH}'),
| (rI, Identifier `MHashTable.readMHRef{v rI}'),
| (rJ, Identifier `MHashTable.writeMHRef{v rJ}'),
| (rK, Identifier `MHashTable.zdp1MutHash{v rK}'),
| (rL, Identifier `MHashTable.new{v rL}'),
| (rM, Identifier `MHashTable.update{v rM}'),
| (rN, Identifier `MHashTable.zdwpolyzuwriteMHArray{v rN}'),
| (rO, Identifier `MHashTable.polyzuwriteMHArray{v rO}'),
| (rP, Identifier `MHashTable.lit{v rP}'),
| (rQ, Identifier `MHashTable.lvl{v rQ}'),
| (rR, Identifier `MHashTable.zdwnew{v rR}')]
|
|
|% make clean
|rm -f *.o *.hi a.out
|
| Removing all generated files: A Fresh Start with another
| definition of new (see attachment):
|
|
|% /var/tmp/ghc/bin/ghc --make -Dnew_undef -no-recomp -O Main.hs
|Chasing modules from: Main.hs
|Compiling MHashTable ( ./MHashTable.hs, ./MHashTable.o )
|Compiling Main ( Main.hs, Main.o )
|Linking ...
|Main.o(.text+0x57): undefined reference to
`MHashTable_updateST_closure'
|Main.o(.rodata+0x0): undefined reference to
`MHashTable_updateST_closure'
|collect2: ld returned 1 exit status
|
|
| Finally, executing the previous command again gives _another_
| error, which is rather weird given that -no-recomp is given...
|
|
|% /var/tmp/ghc/bin/ghc --make -Dnew_undef -no-recomp -O Main.hs
|Chasing modules from: Main.hs
|Compiling MHashTable ( ./MHashTable.hs, ./MHashTable.o )
|Compiling Main ( Main.hs, Main.o )
|ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
6.4.20050304):
| lookupVers1 MHashTable updateST{v}
|
| Good night,
| Remi
|
| --
| Nobody can be exactly like me. Even I have trouble doing it.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: labeled field update kind-error in ghc 6.4.20050215
Excellent bug, thank you. This one has been lurkng for a long time
(it's wrong in 6.2 too) but some recent changes made it surface. Easily
fixed.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Remi Turk
| Sent: 26 February 2005 15:48
| To: glasgow-haskell-bugs@haskell.org
| Subject: labeled field update kind-error in ghc 6.4.20050215
|
| Hello again,
|
| while trying to get HashTable to work both in IO and in ST I
| hit the following probable bug in 6.4.20050215.
| 6.2.1 does accept it, and the #ifdeffed-out version works in
| both. When the typesignature is removed 6.4 does accept it.
|
| Cheers,
| Remi
|
| {-# OPTIONS -cpp -fglasgow-exts #-}
| module Foo where
|
| data HT (ref :: * - *)
| = HT { kcount :: Int }
|
| #if 1
| set_kcount :: Int - HT ref - HT ref
| #endif
|
| #if 1
| set_kcount kc ht = ht{kcount=kc}
| #else
| set_kcount kcount (HT _) = (HT kcount)
| #endif
|
|
| foo.hs:12:19:
| Couldn't match kind `*' against `* - *'
| When matching the kinds of `t :: *' and `ref :: * - *'
| Expected type: HT t
| Inferred type: HT ref
| In the record update: ht {kcount = kc}
| Failed, modules loaded: none.
|
| --
| Nobody can be exactly like me. Even I have trouble doing it.
| ___
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: 6.4.20050215: panic: lookupVers1 MHashTable HT{d}
Ah, this one we fixed a few days ago. Works for me with the head.
Thanks for your well-boiled-down bug reports; they are a lot faster to
fix.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Remi Turk
| Sent: 27 February 2005 02:20
| To: glasgow-haskell-bugs@haskell.org
| Subject: 6.4.20050215: panic: lookupVers1 MHashTable HT{d}
|
| Hi,
|
| while trying to modify Data.HashTable to support both IO and ST
| without simply copying it, 6.4.20050215 again decided it doesn't
| like me:
|
| /tmp/test% touch *.hs
| /tmp/test% /var/tmp/ghc/bin/ghc -O -c MHashTable.hs
| /tmp/test% /var/tmp/ghc/bin/ghc -O --make CompatHashTable.hs
| Chasing modules from: CompatHashTable.hs
| Skipping MHashTable ( ./MHashTable.hs, ./MHashTable.o )
| Compiling CompatHashTable ( CompatHashTable.hs, CompatHashTable.o )
| ghc-6.4.20050215: panic! (the `impossible' happened, GHC version
6.4.20050215):
| lookupVers1 MHashTable HT{d}
|
| To trigger it, compilation must actually be performed in two
| seperate steps, and the second one must be done using --make.
| -O is also a vital ingredient for the panic.
|
| The killing code is attached.
|
| Happy Hacking,
| Remi
|
| --
| Nobody can be exactly like me. Even I have trouble doing it.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: :i EmptyClass shows a superfluous where
good point; now fixed | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Remi Turk | Sent: 26 February 2005 14:46 | To: glasgow-haskell-bugs@haskell.org | Subject: :i EmptyClass shows a superfluous where | | Hi, | | it's not going to cause World War III, but it does seem to be a | tiny regression since 6.2: | | with an empty class, 6.4.20050215 gives: | | *Main :i EmptyClass | class EmptyClass a where -- Defined at foo.hs:1:6 |^ | | where 6.2.1 gave: | | *Main :i EmptyClass | -- EmptyClass is a class, defined at foo.hs:1 | class EmptyClass a |^ | | Groeten, | Remi | | -- | Nobody can be exactly like me. Even I have trouble doing it. | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghc-6.4.20050220: panic! eval_data2tag...
Thanks very much for boiling it down. The data2tag primop is a dark
corner, I'm afraid.
Now fixed, and a test added (cg056)
Simon
| -Original Message-
| From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
| Sent: 22 February 2005 23:20
| To: Simon Marlow; Simon Peyton-Jones
| Cc: glasgow-haskell-bugs@haskell.org
| Subject: Re: ghc-6.4.20050220: panic! eval_data2tag...
|
| Hi,
|
| I managed to distill my program into to the following small example
that
| still exhibits the problem:
|
| module Bug where
| data S e = A | B | C | D | E | F | G | H | I deriving (Eq)
| newtype R = T (S R) deriving (Eq)
|
| The output from 'ghc -c -O Bug.hs' is:
|
| ghc-6.4.20050220: panic! (the `impossible' happened, GHC version
| 6.4.20050220):
| eval_data2tag
| GHCziPrim.dataToTagzh{(w) v 95f}
| @ (Bug.S{tc r14v} recntBug.R{tc r14r})
| (__coerce (Bug.S{tc r14v} recntBug.R{tc r14r}) a{v s1Cm})
|
| Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
|
| --
| Thomas Hallgren
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
