March 2017 - ghc-tickets

[GHC] #13454: Operators not allowed as fields in Record Pattern Synonyms
by GHC 29 Mar '17

29 Mar '17

#13454: Operators not allowed as fields in Record Pattern Synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to write the following record pattern synonym {{{#!hs pattern MkOp :: Op -> Exp -> Exp -> Exp pattern MkOp {(·), a, b} <- (splitOp -> Just ((·), a, b)) where MkOp (·) a b = a · b }}} given this code {{{#!hs data Exp = Val Int | Add Exp Exp | Mul Exp Exp deriving Show type Op = Exp -> Exp -> Exp splitOp :: Exp -> Maybe (Op, Exp, Exp) splitOp (Add a b) = Just (Add, a, b) splitOp (Mul a b) = Just (Mul, a, b) splitOp _ = Nothing }}} It works fine if `(·)` is replaced by `operator`. Fields of regular data types works just fine: {{{#!hs data F a = F { (·) :: a -> a -> a, x :: a, y :: a } f F{(·), x, y} = x·y g F{..} = x·y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13490: Ambiguous types with constraints on new variables
by GHC 29 Mar '17

29 Mar '17

#13490: Ambiguous types with constraints on new variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile: {{{ {-# LANGUAGE FlexibleContexts, TypeFamilies #-} import Data.Typeable type family Foo a data C a foo :: (Typeable (C z), z ~ Foo zp) => C zp foo = undefined }}} with the error {{{ • Could not deduce (Typeable z) from the context: (Typeable (C z), z ~ Foo zp) bound by the type signature for: foo :: (Typeable (C z), z ~ Foo zp) => C zp at Bug.hs:(9,8)-(10,9) • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: (Typeable (C z), z ~ Foo zp) => C zp }}} It's quite unclear why GHC feels thta it needs `Typeable z`. The code compiles if I change the `Typeable` constraint to `Typeable (C (Foo zp))`, which should be identical to what I wrote. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13496: Add Generic instance to GHC.Stack.SrcLoc
by GHC 29 Mar '17

29 Mar '17

#13496: Add Generic instance to GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Useful for deriving orphan instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13496> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5288: Less noisy version of -fwarn-name-shadowing
by GHC 29 Mar '17

29 Mar '17

#5288: Less noisy version of -fwarn-name-shadowing -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think there still needs to be a proper specification and then of course an implementation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5288#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5288: Less noisy version of -fwarn-name-shadowing
by GHC 29 Mar '17

29 Mar '17

#5288: Less noisy version of -fwarn-name-shadowing -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * cc: nathan.collins@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5288#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5288: Less noisy version of -fwarn-name-shadowing
by GHC 29 Mar '17

29 Mar '17

#5288: Less noisy version of -fwarn-name-shadowing -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): +1 (and is there a better way to say "I like this idea" than adding a "+1" comment like this?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5288#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13493: Recompilation avoidance and Backpack
by GHC 28 Mar '17

28 Mar '17

#13493: Recompilation avoidance and Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: recomp | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Today, recompilation avoidance is centered around two major mechanisms: 1. First, we keep track of entities we *use* (`tcg_dus`), which is done by reading off all external names from the renamed source code of a Haskell source file. 2. Second, we keep track of what we *import* (`tcg_imports`), which tracked when we rename imports. These two pieces of information get assembled into a module-indexed series of usages in `mk_mod_usage_info`. The general idea is that when an entity is used, we must record the hash of the entity; when a module is imported, we must record its export hash. There is an implicit assumption here, which is that a (direct) import is the only way we depend on the exports of a module, and an occurrence of a name in the renamed syntax is the only way we depend on an actual entity. Backpack breaks these assumptions: * When we perform signature merging, we depend on the exports and entities of each of the signatures we merge in. Furthermore, it is important to distinguish each of these by identity module (not semantic module, which collapses the distinction.) * When we instantiate a module, we depend on the exports and entities of the implementing module. When I initially implemented Backpack, I slowly added extra information to fix recompilation problems as I noticed them. I thus accreted the following recompilation avoidance mechanisms: * When signature merging occurs, we specially record the module hash for each used merge requirement as a special new field `UsageMergedRequirement`, and recomp if the module hash changed at all. We also add each merged signature to ImportAvails (but not as an "import") to ensure we pick up family instances. * When we instantiate a module, we treat it as if we had a direct import of it (not yet merged, in https://phabricator.haskell.org/D3381) Since instantiations are always referencing non-local modules, we'll always record a module hash in such cases. This is quite a hodgepodge, and I have no confidence that it is correct. For example, if an implementing module reexports an entity from another module, and that original entity changes, I doubt we recompile at this point. We "accidentally" handle the case when it's not a reexport because we record the module hash for the entire instantiating module. It seems that it would be better if we can recast this in terms of imports and usages. Here is a try at the design: * In both instantiation and merging, we must record the export hash of the modules we instantiated/merged in. It is a little troublesome to think of these as imports, however, because they're not (and if you try to implement this, you find yourself making a fake ImportedModVal for an import that doesn't exist); I think the correct thing here is to introduce a new notion of dependency for things that don't correspond to source level imports (another possibility is to add another constructor to ImportedModVal but the effect of this on existing code would have to be determined.) * The usages when we instantiate a signature are the (instantiated) usages of the original signature (in particular, this picks up the usages from instance lookup), plus a usage for each entity that we match against (because we must rematch if the type changes.) * Usages for signature merging are a little trickier. We want a usage for every entity that we end up merging in (so, we must record usages post thinning), BUT we must make sure the usage points at the identity module of the signature that originally provided it, not the semantic module (which will invariably point to the current module under compilation.) One more thing: when we instantiate a module on-the-fly, we need to account for how we instantiated it (to put it differently, the recompilation information we compute when we do on-the-fly should be the (morally) the same as what we would get if we actually compiled the modules in question. This is a bit troublesome since we don't have detailed information relating how a signature was instantiated and what we used (the on-the-fly instantiation process shortcuts this). The simplest thing is probably to just record the module hashes of each module that was used to instantiate an imported module (recursively); we might be able to do this even by just twiddling `mi_mod_hash` hash when we instantiate (the alternative is to switch to recording InstalledModule/InstalledUnitId only in hashes, and augmenting usage information to also carry along instantiations.) Another problem is that we record usages for Module (instantiated things), but hashes are actually on an InstalledModule basis. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502)
by GHC 28 Mar '17

28 Mar '17

#13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently, GHC stopped working for me on my Windows 10 machine. I strongly reckon this has to do with my recent switch to the Windows Insider Fast-Ring builds: I'm currently on version 1703, build 15058. Here's what I got in a mingw shell (ghc 8.0.2 from the core HP, same output with PowerShell): {{{#!hs $ cat << EOF > hw.hs > main = putStrLn "hi" > EOF $ ghc hw.hs [1 of 1] Compiling Main ( hw.hs, hw.o ) `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) }}} This seems to be independent of the GHC version, as I tried `stack setup` with different stack LTSs, which hit the same error when compiling some sanity checks. Currently I'm about to reverting back to Slow-Ring, but when the actual switch is to happen is only known to Bill Gates himself it seems. I believe it will then work again, but this is something to look out for when/if the Fast-Ring changes eventually make it into Windows stable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation
by GHC 28 Mar '17

28 Mar '17

#12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: template | Operating System: Unknown/Multiple haskell, recompilation | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In our project, we get from time to time an error like this: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib }}} I was able to create a somewhat minimal setup for reproducing the problem. I've reproduced the problem on Mac and Linux with GHC 8.0.1, didn't try on Windows. The root of the problem seems to be an interaction with template haskell and the recompilation manager. I'll now explain the setup. I've attached an archive which contains all code and a simple build script. Just unpack the archive and execute ./build.sh to reproduce the problem. The setup consists of four files. (Don't be confused by the module names. They are derived from our project). The problem arises after a change to one of these files and a recompilation. Here are the initial versions of the four files. {{{#!hs -- src/ShortText.hs module ShortText where data ShortText = ShortText String toString :: ShortText -> String toString (ShortText s) = s }}} {{{#!hs -- src/Hospital.hs module Hospital where foo :: Int -> String foo i = show i }}} {{{#!hs -- src/Types.hs {-# LANGUAGE TemplateHaskell #-} module Types where import qualified Hospital import Language.Haskell.TH genCode :: Q [Dec] genCode = let s = Hospital.foo 5 in [d|string = s|] }}} {{{#!hs -- src/MetaHandler.hs {-# LANGUAGE TemplateHaskell #-} module Main where import qualified Types -- splices in "string :: String" $(Types.genCode) main :: IO () main = putStrLn string }}} Compiling the project for the first time works without problems: {{{ $ /Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/bin/ghc -O0 -isrc -ibuild -dynamic -outputdir build -package template-haskell --make src/MetaHandler.hs [1 of 3] Compiling Hospital ( src/Hospital.hs, build/Hospital.o ) [2 of 3] Compiling Types ( src/Types.hs, build/Types.o ) [3 of 3] Compiling Main ( src/MetaHandler.hs, build/Main.o ) Linking src/MetaHandler ... }}} I then changed the content of src/Hospital.hs to use the ShortText module. Here is the new content: {{{#!hs -- src/Hospital.hs module Hospital where import ShortText foo :: Int -> String foo i = toString (ShortText (show i)) }}} Then recompilation fails: {{{ [1 of 4] Compiling ShortText ( src/ShortText.hs, build/ShortText.o ) [2 of 4] Compiling Hospital ( src/Hospital.hs, build/Hospital.o ) [4 of 4] Compiling Main ( src/MetaHandler.hs, build/Main.o ) [TH] ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Looking at the output when compiling with -v3 gives a clue why: {{{ ... *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -dynamiclib -o /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib build/Hospital.o build/Types.o -undefined dynamic_lookup -single_module -install_name '@rpath/libghc_7.dylib' -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /template-haskell-2.11.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /template-haskell-2.11.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/pretty-1.1.3.3 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/pretty-1.1.3.3 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- boot-th-8.0.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- boot-th-8.0.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/integer- gmp-1.0.0.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /integer-gmp-1.0.0.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- prim-0.5.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- prim-0.5.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/rts -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/rts -lHStemplate-haskell-2.11.0.0-ghc8.0.1 -lHSpretty-1.1.3.3-ghc8.0.1 -lHSdeepseq-1.4.2.0-ghc8.0.1 -lHSarray-0.5.1.1-ghc8.0.1 -lHSghc-boot- th-8.0.1-ghc8.0.1 -lHSbase-4.9.0.0-ghc8.0.1 -lHSinteger- gmp-1.0.0.1-ghc8.0.1 -lHSghc-prim-0.5.0.0-ghc8.0.1 -liconv *** Deleting temp files: Deleting: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/ghc_8.rsp /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib *** Deleting temp dirs: Deleting: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0 ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib }}} We can see here that the .o file for ShortText is not passed to gcc when building libghc_7.dylib. I suspect that libghc_7.dylib is used to run template haskell code, but this is only a guess. Looking at the .hi file for MetaHandler, we can see why gcc does not get the .o file for ShortText: ShortText is not included in the module dependencies: {{{ $ /Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/bin/ghc --show-iface build/Main.hi Magic: Wanted 33214052, got 33214052 Version: Wanted [8, 0, 0, 1], got [8, 0, 0, 1] Way: Wanted [], got [d, y, n] interface Main 8001 interface hash: def8085a5dcb4980922089d5d21cf0f9 ABI hash: 1a46783c6a6c6b308503cf705db45d4d export-list hash: d2d75d71ebb6963f6e9c9a5b4050ef71 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: 3468616c2ba87fe39e866ff30d651f01 sig of: Nothing used TH splices: True where exports: main string module dependencies: Hospital Types package dependencies: array-0.5.1.1 base-4.9.0.0 deepseq-1.4.2.0 ghc-boot-th-8.0.1 ghc-prim-0.5.0.0 integer- gmp-1.0.0.1 pretty-1.1.3.3 template-haskell-2.11.0.0 orphans: GHC.Base GHC.Float }}} I think the main problem is that src/Types.hs is not recompiled in the second run. I also experimented with compiling each file separately, using the -c flag. When I then compile src/Types.hs, ghc outputs "compilation NOT required" in the second run. If a compile src/Types.hs with -fforce- recomp in the 2nd run, everything works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13466: Ghci panics with type applications to unknown functions
by GHC 27 Mar '17

27 Mar '17

#13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.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: -------------------------------------+------------------------------------- I haven't investigated further, but I stumbled upon the following: {{{ Prelude> :set -XTypeApplications Prelude> :t nonexistant @[] ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] nonexistant_a2YB :: t_a2YA[tau:3] (CHoleCan: nonexistant)} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13466> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6