October 2015 - ghc-tickets

[GHC] #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide
by GHC 20 Nov '15

20 Nov '15

#10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 Documentation | Keywords: | Operating System: Unknown/Multiple PatternSynonms | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I read the chapter on PatternSynonyms recently. Seems like a very useful feature! Here are my notes, in the same spirit as #10140. == 7.3.9 == * This section starts with a nice example of how pattern synonyms can make some code much clearer. No problems sofar. > Note that in this example, the pattern synonyms Int and Arrow can also be > used as expressions (they are bidirectional). * How can a pattern (synonym) possibly be used as an expression. They seem such different concepts. You say "bidirectional", but what are the directions? You mentioned "constructor-like" before, maybe it's something like that? * This could use an example. * Is `Arrow Int Int` an example of using a pattern synonym as an expression? * What about `pattern Maybe t`, can it also be used as an expression? Why is this not mentioned? What is it doing there anyway, it's not used in either of the functions `collectArgs`, `isInt` and `isIntEndo`. > This is not necessarily the case: unidirectional pattern synonyms can also be > declared with the following syntax * Ok. > We can give an explicit inversion of a pattern synonym using the > following syntax * What does inverting a pattern synonym mean? * You mentioned unidirectional and bidirectional pattern synonyms. Can I invert both? {{{ pattern Head x <- x:xs where Head x = [x] }}} * Weird syntax. But what does it //do//? (I'm very confused now) == 7.3.9.1 == > Either prefix or infix syntax can be used. * I have no idea what this refers to. > For implicitly bidirectional pattern synonyms * This is the first time you mention the word "implicit". > For unidirectional and explicitly-bidirectional pattern synonyms * Ok, now it's getting clear. There seem to be 3 types of pattern synonyms. I wish you had said this earlier. (goes back to read from the beginning: ok I guess the first time you mentioned bidirectional patttern synonyms, they were the implicit ones, and the "explicit inversion" stuff with the weird syntax are the explicit ones.) == 7.3.9.2 == {{{ import Data.Maybe( pattern Just ) }}} * This doesn't compile. It turns out I need the PatternSynonyms extension in the importing module, even though you said in the beginning "it is required for defining them, but //not// for using them". * I later found #10653, so that explains it. Maybe mention that ticket. == 7.3.9.3 == > In the common case where CReq is empty, (), it can be omitted altogether. * Why is it more common for CReq to empty than for CProv to be empty? * What if CProv is empty, but CReq isn't? * What if both are empty, can they both be omitted? > so function f is rejected because the type signature is Maybe a * I tried this example, and f is not rejected at all. **Bug**? == 7.3.9.4 == > A pattern synonym occurrence in a pattern is evaluated by first matching > against the pattern synonym itself, and then on the argument patterns. * Should be "against the //rhs// of the pattern synonym" I think. * This is tricky stuff. Why is pattern synonym semantics not just defined as 'textual substitution'? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_
by GHC 18 Nov '15

18 Nov '15

#10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1-rc1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- These need only an Applicative constaint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText
by GHC 16 Nov '15

16 Nov '15

#10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the lexer, `ITopenExpQuote` can be recognised for '[e|' or '[|'. The token definition needs to capture the original `SourceText`, and pass it through to `ExpBr`, which also needs a `SrcText` field. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens
by GHC 16 Nov '15

16 Nov '15

#11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment there is no way to tell if a given token used its unicode variant or its normal one, except to look at the length of the token. This fails for the unicode '*'. Expose the original source text for unicode variants so that API Annotations can capture them specifically. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9579: Runtime suggests using +RTS when that's not possible
by GHC 15 Nov '15

15 Nov '15

#9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I just ran into a stack overflow in an application, and GHC told me: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. I tried to specify +RTS and got an error saying "Most RTS options are disabled. Link with -rtsopts to enable them." The runtime should not suggest using +RTS when that is not possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10997: Pattern synonym causes Iface error.
by GHC 14 Nov '15

14 Nov '15

#10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the mailing list.. Hello, We have a pattern synonym as follows type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a When we try to use the pattern in a different package, the error was [1 of 1] Compiling Bar ( Bar.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) /tmp/test/p2/.stack- work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux- ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine. This problem did not happen with the following definition of (non polykinded ) Showable type family Showable a :: Constraint where Showable a = (Show a) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10997> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used
by GHC 14 Nov '15

14 Nov '15

#10667: '-g' option generates invalid assembly when '*/*' operator is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Bug is observed when building cpphs-1.19 {{{#!hs module A where x */* y = 42 }}} {{{ $ ghc -fforce-recomp A -g [1 of 1] Compiling A ( A.hs, A.o ) /tmp/ghc23923_0/ghc_2.s: Assembler messages: /tmp/ghc23923_0/ghc_2.s:17:0: Error: bad expression /tmp/ghc23923_0/ghc_2.s:17:0: Warning: missing operand; zero assumed ... }}} The problem here is the following assembly snippet: {{{ .text .align 8 .loc 1 3 1 /* */* */ .quad 12884901911 .quad 0 .quad 15 }}} Would it be worthwile using ';' as a comment instead? Don't know if it's universally portable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10690: Save merged signatures to disk
by GHC 13 Nov '15

13 Nov '15

#10690: Save merged signatures to disk -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The Backpack model of development encourages users to mix signatures together. For example: {{{ unit p where signature H where x :: Int unit q where signature H where y :: Int unit r where include p include q module A where import H(x,y) }}} When `A` imports `H`, it should see both `x` and `y` (i.e. a merged version of the two signatures.) There are two possible ways to implement this: 1. The old strategy: When `A` imports `H`, it somehow "sees" both the interface for H from `p`, and the interface from `q`, and it merges them together on-the-fly. 2. The new strategy: Before compiling `A`, we merge the interfaces together, and use that merged interface as what A imports and gets its export from. Strategy (2) has a few advantages: in separate compilation, it avoids the need to repeatedly merge interfaces together, and it also simplifies GHC in that we don't have to manage on the fly signature merging. Now the challenge: GHC currently assumes that every build product is associated with a source file: however, merged interface files don't have this property. Both `--make` and one-shot `-c` compilation infrastructure is organized around this property. Here's is the proposal for how to slot this in: 1. Eliminate `HscSource` distinction between `HsBootFile` and `HsigFile`: the file is always called `A.hs-boot`. Instead, the type checker simply behaves differently depending on whether or not we know what the underlying implementation of `A` is (passed in using the `-sig-of` flag. If we know the underlying implementation is `containers:Data.Map`, we compile the hs-boot file "signature-style", if we don't, we assume it's `this-package:A` and compile it "boot-style" (Conceivably for cross-unit mutual recursion this will need to be more sophisticated, but this will do for now.) By the way, this means that all signature files now compile to A.hi-boot. 2. We introduce a new `HscSource` type, `HsBootMerge`, representing an `hi` (and stub `o`) file that will be generated by a signature merge. Intuitively, this operation will merge together A.hi-boot as well as any signatures which were brought into scope by a `-package` flag. Unlike `HsSrcFile` and `HsBootFile`, `ModSummary`s that are `HsBootMerge` don't have a source file. 3. When compiling `--make`, for all "signature-style" hs-boot files in the module graph, we generate an `HsBootMerge` summary to serve as the `NotBoot` node of that module name. This means if you `import A`, you're actually importing the `HsBootMerge` that produces `A.hi`. 4. When compiling one-shot, we have a new command for generating the `HsBootMerge`: `ghc --merge-requirements A`. This will go and look for an A.hi-boot as well as any external signatures and merge them together. Note that we can't use the existing compilation pipeline `-c` to generate merged hs-boot files, since these presuppose that there is some input source file, which there is none in this case. 5. When generating a Makefile dependency graph, an entry for an `HsBootMerge` looks like this: {{{ A.o : A.hi-boot A.o : /path/to/ghc/foo-0.1/A.hi # if -include-pkg-deps is added }}} That is to say, an `HsBootMerge` looks like a normal source file that imports each signature it's merging together, but doesn't have a source file associated with it. One downside with this representation is that it makes Makefile rules a little more complicated: how do you build `A.o`? Not with `ghc -c A.hs`, but with `ghc --merge-requirements A`. I'm not sure what the best way of solving this is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10622: Rename Backpack packages to units
by GHC 13 Nov '15

13 Nov '15

#10622: Rename Backpack packages to units -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After today's weekly Backpack call, we have come to the conclusion that we have two different types of "packages" in the Backpack world: 1. Cabal packages, which have a single `.cabal` file and are a unit of distribution which get uploaded to Hackage, and 2. Backpack packages, of which there may be multiple defined in a Backpack file shipped with a Cabal package; and are the building blocks for modular development in the small. It's really confusing to have both of these called packages: thus, we propose to rename all occurrences of Backpack package to unit. A Cabal package may contain MULTIPLE Cabal units, although old-style Cabal files will only define one unit. Here are some of the consequences: 1. We rename `PackageKey` to `UnitId`, as it identifies a unit rather than a Cabal package. (I think this actually makes the function of these identifiers clearer.) We'll also distinguish Cabal-file level `PackageName`s from Backpack-file `UnitName`s. Finally, any given unit will be uniquely identified by an `InstalledUnitId`. 2. The source-level syntax of Backpack files will use `unit` in place of where `package` was used before. 3. For backwards compatibility reasons, we'll sometimes arrange for `PackageName`/`UnitName` and `InstalledUnitId`/`InstalledPackageId` to coincide. Specifically, the unit of a package which has the same `UnitName` as the `PackageName` is treated specially: its `InstalledUnitId` is guaranteed to be the same as the `InstalledPackageId` and it is what is "visible" when a user uses old concepts such as `-package foo-0.1` to select a package. 4. The installed package database is extended to record some number of units per an installed package: the public facing API is that you can register a package CONTAINING some number of units. For old-style packages, there will be only one unit with a matching `UnitName`, so this will be isomorphic to an old style package; however, GHC will grow some new APIs for selecting specific units to bring into scope. GHC really mostly only cares about units, but if a user asks for a package using, e.g. `-package` it will translate this request into a request for the appropriate unit. 5. For old-style packages, Cabal will continue to write and register a package configuration file which implicitly defines a single unit. However, the plan is to give GHC the capacity to generate unit description files (like package description files, but per unit), which Cabal can interpret and use to register packages in the global database using a `ghc-pkg` which can register units and "unitless" package description files which don't implicitly define a unit. (NB: we must create unit description files, because `ghc-pkg recache` is expected to be able to regenerate the database.) (NB: we want to be able to add units for a package separately, because this is how units for indefinite packages are created as they are instantiated with new implementations.) 6. Cabal could also finally grow the "multiple libraries per single Cabal file" support people have wanted; it's just a stylized use of the Backpack facilities. The work plan: 1. Modify `bin-package-db` to reflect the unit/package split, but otherwise keep ghc-pkg and GHC the same (so old-style package description still supported, and interpreted as a package containing one unit.) Source modifications to GHC assume that a package only has one unit. 2. Generalize GHC to work with packages with multiple units 3. Add capability to Cabal/ghc-pkg to register just units. For compilation of Backpack files, GHC will write out units which Cabal will then install to the real registry 4. Backpack! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10678: integer-gmp's runS seems unnecessarily expensive
by GHC 13 Nov '15

13 Nov '15

#10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- integer-gmp uses an unsafePerformIO-like operation to work with mutable BigNats (unsafePerformIO and even the IO type are not yet available, since integer-gmp is a dependency of base): {{{ type S s a = State# s -> (# State# s, a #) -- NB: equivalent of GHC.IO.unsafeDupablePerformIO, see notes there runS :: S RealWorld a -> a runS m = lazy (case m realWorld# of (# _, r #) -> r) {-# NOINLINE runS #-} }}} It's tempting to think of such an operation as "free" like an unsafeCoerce, but it is actually somewhat expensive. Consider `plusBigNat` for instance. (Most BigNat operations have a similar structure.) {{{ plusBigNat :: BigNat -> BigNat -> BigNat plusBigNat x y | isTrue# (eqBigNatWord# x 0##) = y | isTrue# (eqBigNatWord# y 0##) = x | isTrue# (nx# >=# ny#) = go x nx# y ny# | True = go y ny# x nx# where go (BN# a#) na# (BN# b#) nb# = runS $ do mbn@(MBN# mba#) <- newBigNat# na# (W# c#) <- liftIO (c_mpn_add mba# a# na# b# nb#) case c# of 0## -> unsafeFreezeBigNat# mbn _ -> unsafeSnocFreezeBigNat# mbn c# nx# = sizeofBigNat# x ny# = sizeofBigNat# y }}} The assembly for `go` begins {{{ 00000000000001d0 <integerzmgmp_GHCziIntegerziType_zdwgo_info>: 1d0: 49 83 c4 28 add $0x28,%r12 1d4: 4d 3b a5 58 03 00 00 cmp 0x358(%r13),%r12 1db: 77 26 ja 203 <integerzmgmp_GHCziIntegerziType_zdwgo_info+0x33> 1dd: 49 c7 44 24 e0 00 00 movq $0x0,-0x20(%r12) 1e4: 00 00 1e2: R_X86_64_32S .text+0x38 1e6: 4d 89 74 24 e8 mov %r14,-0x18(%r12) 1eb: 49 89 7c 24 f0 mov %rdi,-0x10(%r12) 1f0: 49 89 74 24 f8 mov %rsi,-0x8(%r12) 1f5: 4d 89 04 24 mov %r8,(%r12) 1f9: 4d 8d 74 24 e1 lea -0x1f(%r12),%r14 1fe: e9 00 00 00 00 jmpq 203 <integerzmgmp_GHCziIntegerziType_zdwgo_info+0x33> 1ff: R_X86_64_PC32 integerzmgmp_GHCziIntegerziType_runS_info-0x4 203: ... ; heap overflow }}} This allocates a 5-word closure (containing `a#`, `na#`, `b#`, `nb#`) whose code is at `.text+0x38` and passes it to `runS`, which does some `stg_ap`-y things to call back into the closure, which reads its free variables back from the heap and finally does all the real work. Altogether it's around two dozen instructions compared to if we could call directly from `go` to the argument of `runS`. The old integer-gmp somehow avoided this particular overhead by instead using the implicit "unsafePerformIO" of a foreign import prim which performed both the allocation and the addition. Is this overhead a necessary consequence of doing the work in multiple steps in Haskell? I understand that we cannot allow everything to be inlined and, for example, the `newBigNat#` to be shared between a `plusBigNat` and `minusBigNat` with the same arguments. But once `runS` has done its job of keeping the `newBigNat#/c_mpn_add/unsafeFreeze*` together, it would be nice to eliminate it completely in the backend when compiling `go`, or any inlined version of `go`. I'm not sure whether this should be fixed in the code generator or in integer-gmp itself. I'm also aware that this is a tricky subject but haven't really done my homework on the related tickets, so I might be missing something important! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20