- Glasgow-haskell-users

GHC error message on type mismatch
by Daniel Trstenjak 08 Nov '13

08 Nov '13

Hello, I don't know if I'm the only one struggeling with this GHC error message on type mismatches or it's because I'm not a full time Haskeller, or because I'm not a native english speaker. Couldn't match type `A' with `B´ Expected type: B Actual type: A My problem is with 'Expected' and 'Actual', that I'm often unsure if the compiler is "expecting" something or if I'm the expecting one and the same goes for "actual". I know that the compiler is the expecting one and that I'm given the actual thing, but it's quite often that I'm looking at this error and have to repeat this reasoning. It's strange, because normaly I can memorize such things quite good, but this one bothers me. Perhaps it would be easier for myself if 'Actual type' would be called e.g. 'Given type', I don't know, that just one of the two has a less generic meaning. Greetings, Daniel

8 9

match_co: needs more cases
by Evan Laforge 08 Nov '13

08 Nov '13

I made some strictifying changes and started getting this msg from ghc: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc r46} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc r45})>) <main:Util.TimeVectorStorable.Sample{tc r4e} y{tv a4lK} [tv]> It's not just TimeVectorStorable.Sample (which is indeed stored in Data.Vectors), we also have some mysterious compiler-generated symbols: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc rQA} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc rQz})>) <a{tv a6IH} [tv]> I assume this is harmless, but I didn't see any other references to this error on the web or on the ghc trac so maybe it's new?

4 5

7.8.1 RC
by Austin Seipp 04 Nov '13

04 Nov '13

Hello all, First and foremost, I realize that I said an RC was coming on Friday along with a branch, but I've unfortunately been a bit behind the gun this week, and several things more things have come to my attention recently. For the delay, I am very sorry. Here's an update on the most pertinent tickets and what needs to happen. One thing is that Herbert and I would like to upload many of the bootstrap libraries to hackage to coincide with the release, but this requires a server upgrade that should happen quite soon (thanks to Duncan/Herbert.) Herber and I also went over #8305, which should (in our opinion) certainly be part of the RC so issues can be filed, and clearly documented. Herbert has a patch for this, and I'll review it today. Second, the new OS X release, Mavericks (and, by association, XCode 5) seem to be a little confusing at the moment, and I don't have access to these machines quite yet. Only a Lion machine. One reason this is a delay is because I don't quite understand e.g. #8497 and #8493 in particular. There has also historically been some issues with different OS X builds not working on different platforms due to XCode and/or strange ABI issues, so I need to make my own to double check. Preprocessing seems to becoming a hot issue* on the note of #8493, and this also certainly needs attention once I get my hands on a machine. There's been a lot of pain around making all this 'work correctly', and working by proxy is simply becoming difficult I think, so I just need to dig into it a bit once I have my hands on something. Also relevant to this is that I'll be signing the announcement, and giving out tarballs with checksums(!), so some of these issues must be fixed for distribution (like #5987, which I am still investigating.) Finally, I have some incoming patches to fix a few of the critical priority bugs (related to Windows, mostly,) but they need to be polished and I need to investigate some other things related to them (e.g. due to lack of time, I only have a 'very slow path' fix for #8228, which is a bit annoying. And also this new msys2 thing.) * Richard Smith, if you're out there, I should have listened to you on the LLVM list. I'll learn from this one. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: GHC API: modInfoIsExportedName, String -> Name?
by Daniel Trstenjak 20 Oct '13

20 Oct '13

Hi Ranjit, > I should have added that you should call them after compiling the > particular target (or with the environment obtained after compiling > from a particular target) did you do that? I don't compile anything in my context, but I'm just reading the information of already compiled modules/packages. So if I'm using 'lookupRdrNameInModule' instead of 'tcRnLookupRdrName', than I'm getting the desired information, perhaps that's the difference between your and my use case. But now I'm seeing, that my previous profiling was a bit halfhearted and I missed the real hot spot. After adding several cost centres by hand, I'm seeing that getModuleInfo takes up the most time. Does anyone know why that's the case, why getModuleInfo is so costly and if there's an other way to get the exports of a module? Most allocations seem to be done by getModuleInfo, so getModuleInfo seems to create the data structures holding the complete module information. So there's presumably little hope to get this information faster, right? Greetings, Daniel

1 0

GHC API: modInfoIsExportedName, String -> Name?
by Daniel Trstenjak 20 Oct '13

20 Oct '13

Hi, I wanted to use the GHC API to find if a symbol is exported from a module. The function 'modInfoIsExportedName :: ModuleInfo -> Name -> Bool' seems to do what I want, but how do I convert a symbol string into a 'Name'? Thanks for any hints! Greetings, Daniel

3 4

Why cannot inferred type signatures restrict (potentially) ambiguous type variables?
by adam vogt 14 Oct '13

14 Oct '13

Hello, I have code: {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, ScopedTypeVariables, TypeFamilies #-} class C a b where c :: a -> b instance (int ~ Integer) => C Integer int where c = (+1) c2 :: forall a b c. (C a b, C b c) => a -> c c2 x = c (c x :: b) c2 x = c ((c :: a -> b) x) Why are the type signatures needed? If I leave all of them off, I get: Could not deduce (C a1 a0) arising from the ambiguity check for ‛c2’ from the context (C a b, C a1 a) bound by the inferred type for ‛c2’: (C a b, C a1 a) => a1 -> b from the line: c2 x = c (c x) >From my perspective, it seems that the type signature ghc infers should be able to restrict the ambiguous types as the hand-written signature does. These concerns apply to HEAD (using -XAllowAmbiguousTypes) and ghc-7.6 too. Regards, Adam

3 2

default roles
by Richard Eisenberg 10 Oct '13

10 Oct '13

As you may have heard, /roles/ will be introduced with GHC 7.8. Roles are a mechanism to allow for safe 0-cost conversions between newtypes and their base types. GeneralizedNewtypeDeriving (GND) already did this for class instances, but in an unsafe way -- the feature has essentially been retrofitted to work with roles. This means that some uses of GND that appear to be unsafe will no longer work. See the wiki page [1] or slides from a recent presentation [2] for more info. [1] : http://ghc.haskell.org/trac/ghc/wiki/Roles [2] : http://www.cis.upenn.edu/~eir/papers/2013/roles/roles-slides.pdf I am writing because it's unclear what the *default* role should be -- that is, should GND be allowed by default? Examples follow, but the critical issue is this: * If we allow GND by default anywhere it is type-safe, datatypes (even those that don't export constructors) will not be abstract by default. Library writers would have to use a role annotation everywhere they wish to declare a datatype they do not want users to be able to inspect. (Roles still keep type-*un*safe GND from happening.) * If we disallow GND by default, then perhaps lots of current uses of GND will break. Library writers will have to explicitly declare when they wish to permit GND involving a datatype. Which do we think is better? Examples: The chief example demonstrating the problem is (a hypothetical implementation of) Set: > module Set (Set) where -- note: no constructors exported! > > data Set a = MkSet [a] > insert :: Ord a => a -> Set a -> Set a > ... > {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-} > module Client where > > import Set > > newtype Age = MkAge Int deriving Eq > > instance Ord Age where > (MkAge a) `compare` (MkAge b) = b `compare` a -- flip operands, reversing the order > > class HasSet a where > getSet :: Set a > > instance HasSet Int where > getSet = insert 2 (insert 5 empty) > > deriving instance HasSet Age > > good :: Set Int > good = getSet > > bad :: Set Age > bad = getSet According to the way GND works, `good` and `bad` will have the same runtime representation. But, using Set operations on `bad` would indeed be bad -- because the Ord instance for Age is different than that for Int, Set operations will fail unexpectedly on `bad`. The problem is that Set should really be abstract, but we've been able to break this abstraction with GND. Note that there is no type error in these operations, just wrong behavior. So, if we default to *no* GND, then the "deriving" line above would have an error and this problem wouldn't happen. If we default to *allowing* GND, then the writer of Set would have to include > type role Set nominal in the definition of the Set module to prevent the use of GND. (Why that peculiar annotation? See the linked further reading, above.) Although it doesn't figure in this example, a library writer who wishes to allow GND in the default-no scenario would need a similar annotation > type role Foo representational to allow it. There are clearly reasons for and against either decision, but which is better? Let the users decide! Discussion time: 2 weeks. Thanks! Richard

10 29

Linux deployment requirements for GHC-produced binaries
by Yitzchak Gale 09 Oct '13

09 Oct '13

We received a complaint from one of our customers that the Linux executable for one of our products - compiled using GHC - does not run because of libgmp not being installed on their server. This binary was compiled using GHC 7.4.2 (HP 2012.4.0.0). We hope to be migrating soon to GHC 7.6.3 (HP 2013.2.0.0.). Do GHC-compiled binaries have a dynamic dependence on libgmp? If so, what are the exact requirements we need to communicate to our customers? Does this limit what versions of Linux we can claim that our product supports? Are there similar requirements and limitations regarding GNU Readline? Thanks, Yitz

5 10

cabal upload -- error 404
by Christian Hoener zu Siederdissen 09 Oct '13

09 Oct '13

Hi everybody, Does anybody know what this means and how to resolve it? I have updated my hackage account and can upload via the web interface, just not via cabal. cabal config file is new as well. cabal upload -c dist/PrimitiveArray-0.5.2.0.tar.gz Checking dist/PrimitiveArray-0.5.2.0.tar.gz... Error: dist/PrimitiveArray-0.5.2.0.tar.gz: 404 Not Found Sorry for this being the wrong mailing list ;-) Many thanks, Christian

2 1

RTS option -A affecting cpu-core usage?
by Daniel Trstenjak 08 Oct '13

08 Oct '13

Hi all, I played around with a parallel algorithm and tried to get the GC time down by specifying the RTS option '-A'. But if I'm specifying '-A' than also the usage of the cpu-cores seems to change. Without '-A' I'm getting a total cpu-core usage of '4.44s', with '-A' I'm getting only '1.67s'. Any ideas? Greetings, Daniel Without '-A': ------------- dan@machine ~> ghc-mod-dev find showWindows +RTS -s -N4 XMonad.Util.XUtils 980,770,296 bytes allocated in the heap 552,122,168 bytes copied during GC 163,683,152 bytes maximum residency (11 sample(s)) 4,369,800 bytes maximum slop 280 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1690 colls, 1690 par 2.45s 0.66s 0.0004s 0.0024s Gen 1 11 colls, 10 par 0.98s 0.26s 0.0239s 0.1022s Parallel GC work balance: 18.06% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 1025 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 0.99s ( 0.83s elapsed) GC time 3.43s ( 0.93s elapsed) EXIT time 0.02s ( 0.02s elapsed) Total time 4.44s ( 1.78s elapsed) Alloc rate 995,571,064 bytes per MUT second Productivity 22.7% of total user, 56.5% of total elapsed gc_alloc_block_sync: 53552 whitehole_spin: 0 gen[0].sync: 75 gen[1].sync: 23678 With '-A': ---------- dan@machine ~> ghc-mod-dev find showWindows +RTS -s -N4 -A500m XMonad.Util.XUtils 979,761,872 bytes allocated in the heap 94,043,424 bytes copied during GC 118,609,784 bytes maximum residency (2 sample(s)) 2,844,808 bytes maximum slop 2196 MB total memory in use (0 MB lost due to fragmentati Tot time (elapsed) Avg pause Ma Gen 0 0 colls, 0 par 0.00s 0.00s 0.0000s Gen 1 2 colls, 1 par 0.47s 0.18s 0.0878s Parallel GC work balance: 57.02% (serial 0%, perfect 100%) TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4) SPARKS: 1025 (616 converted, 0 overflowed, 0 dud, 0 GC'd, 409 fizzl INIT time 0.02s ( 0.02s elapsed) MUT time 1.16s ( 1.16s elapsed) GC time 0.47s ( 0.18s elapsed) EXIT time 0.02s ( 0.02s elapsed) Total time 1.67s ( 1.38s elapsed) Alloc rate 844,914,346 bytes per MUT second Productivity 70.8% of total user, 85.9% of total elapsed gc_alloc_block_sync: 33458 whitehole_spin: 0 gen[0].sync: 5372 gen[1].sync: 0

1 1