- ghc-tickets - Haskell.org

[GHC] #15541: package environment files and the GHC API
by GHC 26 Aug '18

26 Aug '18

#15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Keywords: package | Operating System: Unknown/Multiple environment | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: #15513 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The GHC API respects package environment files, which is not documented and was not announced. I consider this to be at least a severe documentation bug. Afaik this goes back to ghc-8.0. #15513 is a ticket that essentially asks for the corresponding entry in the migration guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15541> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15564: Plugin recompilation check panics with inline-java
by GHC 26 Aug '18

26 Aug '18

#15564: Plugin recompilation check panics with inline-java -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: plugins, | Operating System: Unknown/Multiple plugin recompilation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15475 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building https://github.com/tweag/inline-java with the beta release of ghc 8.6.1, I'm getting a panic like the one in #15475. {{{ stack --nix --no-terminal build --test --bench --no-run-tests --no-run- benchmarks ... Log files have been written to: /home/centos/inline-java/.stack-work/logs/ -- While building custom Setup.hs for package inline-java-0.8.4 using: /home/centos/.stack/setup-exe-cache/x86_64-linux-nix/Cabal- simple_mPHDZzAJ_2.4.0.0_ghc-8.6.0.20180810 --builddir=.stack- work/dist/x86_64-linux-nix/Cabal-2.4.0.0 build lib:inline-java test:spec --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Logs have been written to: /home/centos/inline-java/.stack-work/logs /inline-java-0.8.4.log Configuring inline-java-0.8.4... Preprocessing library for inline-java-0.8.4.. Building library for inline-java-0.8.4.. [4 of 4] Compiling Language.Java.Inline.Plugin ( src/Language/Java/Inline/Plugin.hs, .stack-work/dist/x86_64-linux- nix/Cabal-2.4.0.0/build/Language/Java/Inline/Plugin.o ) Preprocessing test suite 'spec' for inline-java-0.8.4.. Building test suite 'spec' for inline-java-0.8.4.. [1 of 3] Compiling Language.Java.InlineSpec ( tests/Language/Java/InlineSpec.hs, .stack-work/dist/x86_64-linux- nix/Cabal-2.4.0.0/build/spec/spec-tmp/Language/Java/InlineSpec.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180810 for x86_64-unknown-linux): mkPluginUsage: file not found Language.Java.Inline.Plugin /nix/store /5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib/libHSinline-java-0.8.4 -JByd5xgK6QcDkJNlDDk6Qy-ghc8.6.0.20180810.so Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [centos@ip-172-31-4-204 inline-java]$ stack --nix --no-terminal exec -- env | grep LD_LIBRARY_PATH LD_LIBRARY_PATH=/nix/store/d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk- 8u181b13/lib/openjdk/jre/lib/amd64/server/lib:/nix/store /rc9ksilfsx1pqya4lj8barzzywnvlncl-git-2.18.0/lib:/nix/store /d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk-8u181b13/lib:/nix/store /5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib }}} The fact that ghc tries to locate a library in {{/nix/store /5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib}} to check for recompilation makes me think that this is an actual bug in GHC. But I would be happy to get some assistance to confirm this. I tried disabling recompilation checking by defining the plugin as: {{{ plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install , pluginRecompile = purePlugin } }}} but the error persists. This is what my dependencies look like in stack.yaml: {{{ packages: - . - jni - jvm - jvm-batching - jvm-streaming - examples/classpath - location: singletons extra-dep: true - location: criterion extra-dep: true - location: polyparse-1.12 extra-dep: true extra-deps: - distributed-closure-0.3.5 - git: https://github.com/haskell/cabal # commit: ac461b381104a39a349d7416ecf1399805c6d000 commit: fe10982db1f2fa7d828fc5f8ddaa5beedceaddec subdirs: - Cabal # - git: https://github.com/goldfirere/singletons.git # commit: 5f867ace69ab12fc98fa71df1cdf7985afa3cb91 - git: https://github.com/haskell/stm.git commit: 4a1deb98fc95e55d8a6762a7dfec1a7dfa8b49b2 - git: https://github.com/goldfirere/th-desugar commit: 0f0a45f7b1f290a6005e6d9d849247f8c3d35429 - git: https://github.com/simonmar/async.git commit: 725ba4bb9679c5d9c7fe0e2d45fda4f470851d40 - git: https://github.com/erikd/vector-algorithms.git commit: 89e87b374d94e8a0c90fc58079ea1343c3ffa7c9 - cpphs-1.20.8 }}} I'll see to share my modifications to singletons, criterion and polyparse, if necessary. I just fixed some dependency bounds and added MonadFail instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly.
by GHC 25 Aug '18

25 Aug '18

#14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- During the implementation of relocation capabilities in GHC for linux and macOS it came to light, that windows (which has had this support for quite some time), uses a custom implementation of `getExecutablePath`. Ideally this logic should be moved into `base`. Phyx- noted in D4121 that this should be possible for 8.6, as at that point Win32 should be new enough to be usable in base for this. The result would be that the custom code in GHC (SysTools) and the older copy in GhcPkg of the same code can be unified with the linux and macOS CPP conditional branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14483> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14460: Can't decompose ghc.exe path
by GHC 25 Aug '18

25 Aug '18

#14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I downloaded the haskell platform, but when I try to use ghci I get this message: ghc.exe: panic!(the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "H:\\Programs\\Haskell\\8.2.1\\bin\\ghc.exe" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14460> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase")
by GHC 25 Aug '18

25 Aug '18

#14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: FreeBSD 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: -------------------------------------+------------------------------------- The scenario showed as below: {{{ # This is a FreeBSD Jail for testing $ freebsd-version 11.1-RELEASE $ pkg info # (related packages only) binutils-2.28,1 GNU binary tools gcc-ecj-4.5 Eclipse Java Compiler used to build GCC Java gcc5-5.4.0_2 GNU Compiler Collection 5 gmake-4.2.1_1 GNU version of 'make' utility gmp-6.1.2 Free library for arbitrary precision arithmetic libiconv-1.14_10 Character set conversion library libunistring-0.9.7 Unicode string library mpc-1.0.3 Library of complex numbers with arbitrarily high precision mpfr-3.1.5_1 Library for multiple-precision floating- point computations perl5-5.24.1_1 Practical Extraction and Report Language $ ls -l /usr/local/lib/lib{iconv,charset,gmp}.* -rw-r--r-- 1 root wheel 6864 Jul 13 09:10 /usr/local/lib/libcharset.a lrwxr-xr-x 1 root wheel 19 Jul 13 09:10 /usr/local/lib/libcharset.so -> libcharset.so.1.0.0 lrwxr-xr-x 1 root wheel 19 Jul 13 09:10 /usr/local/lib/libcharset.so.1 -> libcharset.so.1.0.0 -rw-r--r-- 1 root wheel 10733 Jul 13 09:10 /usr/local/lib/libcharset.so.1.0.0 -rw-r--r-- 1 root wheel 1252196 Jul 13 09:23 /usr/local/lib/libgmp.a lrwxr-xr-x 1 root wheel 16 Jul 13 09:23 /usr/local/lib/libgmp.so -> libgmp.so.10.3.2 lrwxr-xr-x 1 root wheel 16 Jul 13 09:23 /usr/local/lib/libgmp.so.10 -> libgmp.so.10.3.2 -rwxr-xr-x 1 root wheel 531728 Jul 13 09:23 /usr/local/lib/libgmp.so.10.3.2 -rw-r--r-- 1 root wheel 1110392 Jul 13 09:10 /usr/local/lib/libiconv.a lrwxr-xr-x 1 root wheel 17 Jul 13 09:10 /usr/local/lib/libiconv.so -> libiconv.so.2.5.1 lrwxr-xr-x 1 root wheel 17 Jul 13 09:10 /usr/local/lib/libiconv.so.2 -> libiconv.so.2.5.1 -rw-r--r-- 1 root wheel 1076449 Jul 13 09:10 /usr/local/lib/libiconv.so.2.5.1 # installed using # env CC=/usr/local/bin/gcc5 LDFLAGS='-Wl,-rpath=/usr/local/lib/gcc5' ./configure --prefix=/home/ghc $ /home/ghc/bin/ghc --numeric-version 8.2.1 $ cat /home/ghc/lib/ghc-8.2.1/settings [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "/usr/local/bin/gcc5"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold"), ("C compiler supports -no-pie", "NO"), ("Haskell CPP command","/usr/local/bin/gcc5"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "ld.gold"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/local/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/local/bin/perl"), ("cross compiling", "NO"), ("target os", "OSFreeBSD"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "@HaskellHaveRTSLinker@"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] $ /home/ghc/bin/ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> (!!6) $ scanl (*) 1 [1..] 720 $ cat Main.hs module Main (main) where main :: IO () main = putStrLn "hello world" $ /home/ghc/bin/ghc -O0 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... In file included from /home/ghc/lib/ghc-8.2.1/include/rts/Threads.h:19:0: error: 0, from /home/ghc/lib/ghc-8.2.1/include/Rts.h:173, from /tmp/ghc28144_0/ghc_4.c:1: /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include- fixed/sys/types.h:266:9: error: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ | 266 | typedef __vm_ooffset_t vm_ooffset_t; | ^ /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include- fixed/sys/types.h:268:9: error: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ | 268 | typedef __vm_pindex_t vm_pindex_t; | ^ `gcc5' failed in phase `C Compiler'. (Exit code: 1) }}} On my FreeBSD 10.3 box: {{{ $ freebsd-version 10.3-STABLE $ pkg info binutils-2.28,1 GNU binary tools gcc-5.4.0_2 Meta-port for the default version of the GNU Compiler Collection gcc-ecj-4.5 Eclipse Java Compiler used to build GCC Java gcc5-5.4.0_3 GNU Compiler Collection 5 gmake-4.2.1_1 GNU version of 'make' utility gmp-6.1.2 Free library for arbitrary precision arithmetic libffi-3.2.1 Foreign Function Interface libiconv-1.14_10 Character set conversion library perl5-5.24.1_1 Practical Extraction and Report Language $ cat ./ghc-8.2.1-bin/lib/ghc-8.2.1/settings [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold"), ("C compiler supports -no-pie", "NO"), ("Haskell CPP command","gcc"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "ld.gold"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "NO"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/local/bin/perl"), ("cross compiling", "NO"), ("target os", "OSFreeBSD"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "@HaskellHaveRTSLinker@"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] $ ./ghc-8.2.1-bin/bin/ghc -O0 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main hello, world! }}} I also noticed that using FreeBSD's strip (from elftoolchain), the {{{ Installing library in /home/ghc/lib/ghc-8.2.1/ghc-prim-0.5.1.0 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /integer-gmp dist-install "strip" '' '/home/ghc' '/home/ghc/lib/ghc-8.2.1' '/home/ghc/share/doc/ghc- 8.2.1/html/libraries' 'v p dyn' }}} phase will be a bit longer than GNU's strip. (Tested by put my $LOCALBASE/bin ahead in $PATH). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14012: External interpreter fails on FreeBSD
by GHC 25 Aug '18

25 Aug '18

#14012: External interpreter fails on FreeBSD ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ $ inplace/bin/ghc-stage2 -fexternal-interpreter --interactive GHCi, version 8.3.20170722: http://www.haskell.org/ghc/ :? for help {handle: <file descriptor: 12>}: GHCi.Message.remoteCall: end of file }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64
by GHC 25 Aug '18

25 Aug '18

#4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by arrowd): * cc: arrowd@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4022#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64
by GHC 25 Aug '18

25 Aug '18

#4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arrowd): I'm maintaining GHC port for FreeBSD, so feel free to ping me if you need something. I'm also poking with stack, making it support installations of recent GHC versions. That's why we need working bindists for FreeBSD. Would it be possible to produce a bindist for 8.4.3 too, at least? And another thought - maybe I can add some logic to create bindist right into FreeBSD port? So you just do `make -C /usr/ports/lang/ghc bindist` on a fresh system and get a tarball. Would that ease anything for you? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4022#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11470: Support changing cross compiler target at runtime
by GHC 24 Aug '18

24 Aug '18

#11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Relevant mailing list thread: https://mail.haskell.org/pipermail/ghc- devs/2016-January/011064.html At the moment, GHC's cross-compiling support requires you to build a cross-compiler for every target platform from scratch. (https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation) There are two reasons for this: 1. GHC uses a configure script to interrogate the GCC toolchain about the vagaries of cross-compilation, some parameters of which get baked into various build system scripts and header files and such. Some of this information wends its way into the final built GHC executable. 2. GHC needs to build the boot libraries, using the stage 1 compiler, targeting the cross compiler. It would be very useful to move this configuration from configure time to run time, so that a user can use GHC as a cross-compiler without having to recompile GHC. That is, we would like to (1) ensure that any information from the configure script can alternately be supplemented at runtime, (2) that users can cross-compile the boot libraries on-demand (since GHC won't ship with the ARM versions of the boot libraries), and (3) rearchitect GHC internally so that it handles knows to keep separate the interface files/package database for various cross compilation targets. Such a change will make cross-compiling more convenient (the iOS cross- compiler currently requires GHC to be built twice, once for ARM and once for the simulator!) and will also pave the way for supporting Template Haskell and compiler plugins in the cross-compiler, since a GHC that knows how to deal with both the target and host platforms can simply ensure that it only loads code built for the host platform (a user can then, if necessary, build code twice, once for the host for Template Haskell, and once for the target). Unclear points of design: * How should GHC get the information about the GCC cross-compiler toolchain (which currently is gotten by `configure`?) Preferably, not by running a `configure` script every time you invoke it. What is this information anyway? * How should GHC rebuild the boot libraries? Maybe `cabal-install` can simply handle this for you. Note: please update the top of this ticket as the design becomes clearer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10346: Cross-module SpecConstr
by GHC 24 Aug '18

24 Aug '18

#10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type-class specialisation now happens flawlessly across modules. That is, if I define {{{ module DefineF where f :: Num a => a -> a {-# INLINEABLE f #-} f x = ...f x'.... }}} then modules that import `DefineF` and call `f` at some particular type (say `Int`) will generate a specialised copy of `f`'s code. But this does not happen for `SpecConstr`; we only specialise a function for calls made in the same module. All the infrastructure is in place to allow cross-module `SpecConstr`; it just hasn't been done yet. This ticket is to record the idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19