- Glasgow-haskell-users

add constraint to the context of the RULE
by Claude Heiland-Allen 20 Mar '17

20 Mar '17

Hi all, I have these functions: toDouble :: (Rounding r, Precision p) => Rounded r p -> Double fromDouble :: (Rounding r, Precision p) => Double -> Rounded r p and I want to use RULES for optimization: {-# RULES "realToFrac/toDouble" realToFrac = toDouble #-} {-# RULES "realToFrac/fromDouble" realToFrac = fromDouble #-} This doesn't work. I found out (thanks to Stack Overflow via #haskell) that I can modify the first rule to the following, which does compile and also seems to fire in a simple test: {-# RULES "realToFrac/toDouble" forall (x :: (Rounding r, Precision p) => Rounded r p) . realToFrac x = toDouble x #-} But I'm at a loss with the fromDouble rule, the error message is: • Could not deduce (Rounding r) arising from a use of ‘fromDouble’ from the context: (Real Double, Fractional (Rounded r p)) bound by the RULE "realToFrac/fromDouble" at src/Numeric/Rounded.hs:359:11-57 Possible fix: add (Rounding r) to the context of the RULE "realToFrac/fromDouble" • In the expression: fromDouble When checking the transformation rule "realToFrac/fromDouble" How do I apply the "possible fix" to the fromDouble rule? Is it even possible with the RULES syntax? Note, there are these instances (among others): instance (Rounding r, Precision p) => Real (Rounded r p) instance (Rounding r, Precision p) => Fractional (Rounded r p) Full code at https://code.mathr.co.uk/rounded (claude5 branch). Thanks for any insight, Claude -- https://mathr.co.uk

1 0

warn-identities from newtype deriving
by Evan Laforge 14 Mar '17

14 Mar '17

I just noticed that if you derive Real for a Ratio.Rational newtype, you get a warning: {-# LANGUAGE GeneralizedNewtypeDeriving #-} import qualified Data.Ratio as Ratio newtype X = X Ratio.Rational deriving (Eq, Ord, Num, Real) You get a warning: <no location info>: Warning: Call of toRational :: Rational -> Rational can probably be omitted (Use -fno-warn-identities to suppress this message) I suppose the automatic Real instance uses toRational to, um, define toRational? In any case, the <no location info> is certainly a bug, but it looks like ghc 8.0.2 has fixed it. Aside from that, it would be nice to automatically suppress warn-identities and unused code warnings in general for automatically generated code that we don't really have any control over and can't see in the source. It's easily worked around with OPTIONS_GHC to turn off the warning, but it's confusing the first time you see it.

1 0

Re: GHC on Windows 10 15019+
by Tamar Christina 11 Mar '17

11 Mar '17

Hi Garrett, Thanks for the report. I've managed to reproduce the issue and have opened a ticket here https://ghc.haskell.org/trac/ghc/ticket/13411. Just the clarify the issue isn't with mingw-w64 or the bundled GCC version. It is with the gcc driver that we built to override and set some default parameters. the actual gcc binary is called realgcc.exe, when you replaced the binaries you overwrote the wrapper, which may be what's causing your spaces issue. Tamar

1 0

GHC on Windows 10 15019+
by J. Garrett Morris 09 Mar '17

09 Mar '17

Hi y'all, I've recently run into a problem using released version of GHC on Windows 10, builds 15019 and later. The problem seems to be an incompatibility with Mingw64---builds fail calling realgcc.exe with vaguely incomprehensible error messages (Program failed to start with error 0xc0000142). Replacing the packaged version of Mingw64 with a more recent build (from Msys2, say) restores functioning, but no longer works if there are spaces in the path to GHC. I've observed this on three different machines, so I don't think it's just a configuration oddity. Has anyone else encountered similar problems, or can anyone else verify? If so, it might be worth repackaging at least the latest released version with a more recent Mingw64. /g -- Prosperum ac felix scelus virtus vocatur -- Seneca The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: accelerate-llvm problems
by dominic＠steinitz.org 04 Mar '17

04 Mar '17

I created an issue here: https://github.com/bscarlet/llvm-general/issues/207 > On 3 Mar 2017, at 16:44, Dominic Steinitz <idontgetoutmuch(a)gmail.com> wrote: > > Hi Trevor, > > I installed llvm with shared libraries: > >> brew install llvm --with-shared-libs > > But I now get > >> llvm-general/llvm-general $ git branch >> git branch >> llvm-3.8 >> * llvm-3.9 >> master > > > >> cabal configure -fshared-llvm --extra-lib-dirs=/usr/local/opt/llvm/lib --extra-include-dirs=/usr/local/opt/llvm/include >> Warning: The package list for 'hackage.haskell.org <http://hackage.haskell.org/>' is 30 days old. >> Run 'cabal update' to get the latest list of available packages. >> Resolving dependencies... >> Configuring llvm-general-3.9.0.0... >> Warning: Instead of 'cc-options: -I/usr/local/Cellar/llvm/3.9.1/include' use >> 'include-dirs: /usr/local/Cellar/llvm/3.9.1/include' >> setup: Missing dependency on a foreign library: >> * Missing C library: LLVM-3.9.1 >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the library is >> already installed but in a non-standard location then you can use the flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > > Perhaps I should report this here: https://github.com/bscarlet/llvm-general/issues? <https://github.com/bscarlet/llvm-general/issues?> > > >> On 21 Feb 2017, at 23:44, Trevor McDonell <trevor.mcdonell(a)gmail.com <mailto:trevor.mcdonell@gmail.com>> wrote: >> >> Hi Dominic, >> >> You need to build/install LLVM with shared libraries. >> >> Then, install llvm-general with -fshared-llvm (or, use my fork, which the stack.yaml files point to). >> >> >> -Trev >> >> P.S. On mobile, apologies for the terse reply. >> On Wed, 22 Feb 2017 at 10:34 AM, Dominic Steinitz <idontgetoutmuch(a)gmail.com <mailto:idontgetoutmuch@gmail.com>> wrote: >> I am trying to build accelerate-llvm but getting the ghc panics below. Here’s my config >> >> > bash-3.2$ ghc-pkg list | grep llvm >> > ghc-pkg list | grep llvm >> > llvm-general-3.8.0.0 >> > llvm-general-pure-3.5.0.0 >> > llvm-general-pure-3.5.1.0 >> > llvm-general-pure-3.8.0.0 >> > bash-3.2$ ghc-pkg list | grep acc >> > ghc-pkg list | grep acc >> > accelerate-1.0.0.0 >> > bash-3.2$ ghc --version >> > ghc --version >> > The Glorious Glasgow Haskell Compilation System, version 7.10.2 >> >> If anyone has any ideas, I’d be very grateful. >> >> > bash-3.2$ ~/Library/Haskell/bin/cabal build >> > ~/Library/Haskell/bin/cabal build >> > Building accelerate-llvm-1.0.0.0... >> > Preprocessing library accelerate-llvm-1.0.0.0... >> > ghc: >> > lookupSymbol failed in relocateSection (RELOC_GOT) >> > /usr/local/Cellar/llvm(a)3.8/3.8.1/lib/llvm-3.8/lib/libLLVMSupport.a: unknown symbol `___dso_handle' >> > [24 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > >> > [31 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) >> > >> > <no location info>: >> > ghc: unable to load package `llvm-general-3.8.0.0' >> > [32 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > >> > [33 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Monad[boot] ( Data/Array/Accelerate/LLVM/CodeGen/Monad.hs-boot, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Monad.o-boot ) >> > [34 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.IR <http://data.array.accelerate.llvm.codegen.ir/> ( Data/Array/Accelerate/LLVM/CodeGen/IR.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/IR.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > >> > [44 of 52] Compiling Data.Array.Accelerate.LLVM.Execute.Environment ( Data/Array/Accelerate/LLVM/Execute/Environment.hs, dist/build/Data/Array/Accelerate/LLVM/Execute/Environment.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > > Dominic Steinitz > dominic(a)steinitz.org <mailto:dominic@steinitz.org> > http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/> Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

Fwd: accelerate-llvm problems
by dominic＠steinitz.org 03 Mar '17

03 Mar '17

> Begin forwarded message: > > From: Dominic Steinitz <idontgetoutmuch(a)gmail.com> > Subject: Re: accelerate-llvm problems > Date: 3 March 2017 at 16:44:59 GMT > To: Trevor McDonell <trevor.mcdonell(a)gmail.com> > Cc: GHC users <glasgow-haskell-users(a)haskell.org>, Ben Lippmeier <benl(a)ouroborus.net> > > Hi Trevor, > > I installed llvm with shared libraries: > >> brew install llvm --with-shared-libs > > But I now get > >> llvm-general/llvm-general $ git branch >> git branch >> llvm-3.8 >> * llvm-3.9 >> master > > > >> cabal configure -fshared-llvm --extra-lib-dirs=/usr/local/opt/llvm/lib --extra-include-dirs=/usr/local/opt/llvm/include >> Warning: The package list for 'hackage.haskell.org <http://hackage.haskell.org/>' is 30 days old. >> Run 'cabal update' to get the latest list of available packages. >> Resolving dependencies... >> Configuring llvm-general-3.9.0.0... >> Warning: Instead of 'cc-options: -I/usr/local/Cellar/llvm/3.9.1/include' use >> 'include-dirs: /usr/local/Cellar/llvm/3.9.1/include' >> setup: Missing dependency on a foreign library: >> * Missing C library: LLVM-3.9.1 >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the library is >> already installed but in a non-standard location then you can use the flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > > Perhaps I should report this here: https://github.com/bscarlet/llvm-general/issues? <https://github.com/bscarlet/llvm-general/issues?> > > >> On 21 Feb 2017, at 23:44, Trevor McDonell <trevor.mcdonell(a)gmail.com <mailto:trevor.mcdonell@gmail.com>> wrote: >> >> Hi Dominic, >> >> You need to build/install LLVM with shared libraries. >> >> Then, install llvm-general with -fshared-llvm (or, use my fork, which the stack.yaml files point to). >> >> >> -Trev >> >> P.S. On mobile, apologies for the terse reply. >> On Wed, 22 Feb 2017 at 10:34 AM, Dominic Steinitz <idontgetoutmuch(a)gmail.com <mailto:idontgetoutmuch@gmail.com>> wrote: >> I am trying to build accelerate-llvm but getting the ghc panics below. Here’s my config >> >> > bash-3.2$ ghc-pkg list | grep llvm >> > ghc-pkg list | grep llvm >> > llvm-general-3.8.0.0 >> > llvm-general-pure-3.5.0.0 >> > llvm-general-pure-3.5.1.0 >> > llvm-general-pure-3.8.0.0 >> > bash-3.2$ ghc-pkg list | grep acc >> > ghc-pkg list | grep acc >> > accelerate-1.0.0.0 >> > bash-3.2$ ghc --version >> > ghc --version >> > The Glorious Glasgow Haskell Compilation System, version 7.10.2 >> >> If anyone has any ideas, I’d be very grateful. >> >> > bash-3.2$ ~/Library/Haskell/bin/cabal build >> > ~/Library/Haskell/bin/cabal build >> > Building accelerate-llvm-1.0.0.0... >> > Preprocessing library accelerate-llvm-1.0.0.0... >> > ghc: >> > lookupSymbol failed in relocateSection (RELOC_GOT) >> > /usr/local/Cellar/llvm(a)3.8/3.8.1/lib/llvm-3.8/lib/libLLVMSupport.a: unknown symbol `___dso_handle' >> > [24 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > >> > [31 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) >> > >> > <no location info>: >> > ghc: unable to load package `llvm-general-3.8.0.0' >> > [32 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > >> > [33 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Monad[boot] ( Data/Array/Accelerate/LLVM/CodeGen/Monad.hs-boot, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Monad.o-boot ) >> > [34 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.IR <http://data.array.accelerate.llvm.codegen.ir/> ( Data/Array/Accelerate/LLVM/CodeGen/IR.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/IR.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > >> > [44 of 52] Compiling Data.Array.Accelerate.LLVM.Execute.Environment ( Data/Array/Accelerate/LLVM/Execute/Environment.hs, dist/build/Data/Array/Accelerate/LLVM/Execute/Environment.o ) >> > >> > <no location info>: >> > ghc: panic! (the 'impossible' happened) >> > (GHC version 7.10.2 for x86_64-apple-darwin): >> > Dynamic linker not initialised >> > >> > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> >> > > Dominic Steinitz > dominic(a)steinitz.org <mailto:dominic@steinitz.org> > http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/> Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

Folding over short static lists
by Joachim Breitner 28 Feb '17

28 Feb '17

Hi, a common pattern is x `elem` [a,b,c] or x `elem` "/!#" instead of x == a || x == b || x == c or x == '/' || x == '!' || x == '#'. This used to be also what hlint suggested, although that hint was removed https://github.com/ndmitchell/hlint/issues/31. Upon closer inspection it seems that the compiler is not optimizing the former to the latter (more efficient, as allocation-free) form, which mildly surprised me. I guess the problem is described in this note in GHC/Base.hs: -- The foldr/cons rule looks nice, but it can give disastrously -- bloated code when commpiling -- array (a,b) [(1,2), (2,2), (3,2), ...very long list... ] -- i.e. when there are very very long literal lists -- So I've disabled it for now. We could have special cases -- for short lists, I suppose. -- "foldr/cons" forall k z x xs. foldr k z (x:xs) = k x (foldr k z xs) Now I am quite demanding of my compiler, and in particular I expect it to make a more informed choice here. Is there a good way of making an informed choice here? Up to what length of the list is it a good idea to do this? And can we implement it? Maybe simply with a few static rules for list lengths up to a certain, short length? (Maybe I should try that on a branch and see what perf.haskell.org has to say about it.) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Re: accelerate-llvm problems
by Trevor McDonell 22 Feb '17

22 Feb '17

Hi Dominic, You need to build/install LLVM with shared libraries. Then, install llvm-general with -fshared-llvm (or, use my fork, which the stack.yaml files point to). -Trev P.S. On mobile, apologies for the terse reply. On Wed, 22 Feb 2017 at 10:34 AM, Dominic Steinitz <idontgetoutmuch(a)gmail.com> wrote: > I am trying to build accelerate-llvm but getting the ghc panics below. > Here’s my config > > > bash-3.2$ ghc-pkg list | grep llvm > > ghc-pkg list | grep llvm > > llvm-general-3.8.0.0 > > llvm-general-pure-3.5.0.0 > > llvm-general-pure-3.5.1.0 > > llvm-general-pure-3.8.0.0 > > bash-3.2$ ghc-pkg list | grep acc > > ghc-pkg list | grep acc > > accelerate-1.0.0.0 > > bash-3.2$ ghc --version > > ghc --version > > The Glorious Glasgow Haskell Compilation System, version 7.10.2 > > If anyone has any ideas, I’d be very grateful. > > > bash-3.2$ ~/Library/Haskell/bin/cabal build > > ~/Library/Haskell/bin/cabal build > > Building accelerate-llvm-1.0.0.0... > > Preprocessing library accelerate-llvm-1.0.0.0... > > ghc: > > lookupSymbol failed in relocateSection (RELOC_GOT) > > /usr/local/Cellar/llvm(a)3.8/3.8.1/lib/llvm-3.8/lib/libLLVMSupport.a: > unknown symbol `___dso_handle' > > [24 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, > dist/build/Data/Range/Range.o ) > > > > <no location info>: > > ghc: panic! (the 'impossible' happened) > > (GHC version 7.10.2 for x86_64-apple-darwin): > > Dynamic linker not initialised > > > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > [31 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( > Data/Array/Accelerate/LLVM/Util.hs, > dist/build/Data/Array/Accelerate/LLVM/Util.o ) > > > > <no location info>: > > ghc: unable to load package `llvm-general-3.8.0.0' > > [32 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( > Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, > dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) > > > > <no location info>: > > ghc: panic! (the 'impossible' happened) > > (GHC version 7.10.2 for x86_64-apple-darwin): > > Dynamic linker not initialised > > > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > [33 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Monad[boot] ( > Data/Array/Accelerate/LLVM/CodeGen/Monad.hs-boot, > dist/build/Data/Array/Accelerate/LLVM/CodeGen/Monad.o-boot ) > > [34 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.IR ( > Data/Array/Accelerate/LLVM/CodeGen/IR.hs, > dist/build/Data/Array/Accelerate/LLVM/CodeGen/IR.o ) > > > > <no location info>: > > ghc: panic! (the 'impossible' happened) > > (GHC version 7.10.2 for x86_64-apple-darwin): > > Dynamic linker not initialised > > > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > [44 of 52] Compiling Data.Array.Accelerate.LLVM.Execute.Environment ( > Data/Array/Accelerate/LLVM/Execute/Environment.hs, > dist/build/Data/Array/Accelerate/LLVM/Execute/Environment.o ) > > > > <no location info>: > > ghc: panic! (the 'impossible' happened) > > (GHC version 7.10.2 for x86_64-apple-darwin): > > Dynamic linker not initialised > > > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > >

2 2

accelerate-llvm problems
by Dominic Steinitz 21 Feb '17

21 Feb '17

I am trying to build accelerate-llvm but getting the ghc panics below. Here’s my config > bash-3.2$ ghc-pkg list | grep llvm > ghc-pkg list | grep llvm > llvm-general-3.8.0.0 > llvm-general-pure-3.5.0.0 > llvm-general-pure-3.5.1.0 > llvm-general-pure-3.8.0.0 > bash-3.2$ ghc-pkg list | grep acc > ghc-pkg list | grep acc > accelerate-1.0.0.0 > bash-3.2$ ghc --version > ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.10.2 If anyone has any ideas, I’d be very grateful. > bash-3.2$ ~/Library/Haskell/bin/cabal build > ~/Library/Haskell/bin/cabal build > Building accelerate-llvm-1.0.0.0... > Preprocessing library accelerate-llvm-1.0.0.0... > ghc: > lookupSymbol failed in relocateSection (RELOC_GOT) > /usr/local/Cellar/llvm(a)3.8/3.8.1/lib/llvm-3.8/lib/libLLVMSupport.a: unknown symbol `___dso_handle' > [24 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) > > <no location info>: > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-apple-darwin): > Dynamic linker not initialised > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> > > [31 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) > > <no location info>: > ghc: unable to load package `llvm-general-3.8.0.0' > [32 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) > > <no location info>: > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-apple-darwin): > Dynamic linker not initialised > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> > > [33 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Monad[boot] ( Data/Array/Accelerate/LLVM/CodeGen/Monad.hs-boot, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Monad.o-boot ) > [34 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.IR ( Data/Array/Accelerate/LLVM/CodeGen/IR.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/IR.o ) > > <no location info>: > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-apple-darwin): > Dynamic linker not initialised > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug> > > [44 of 52] Compiling Data.Array.Accelerate.LLVM.Execute.Environment ( Data/Array/Accelerate/LLVM/Execute/Environment.hs, dist/build/Data/Array/Accelerate/LLVM/Execute/Environment.o ) > > <no location info>: > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-apple-darwin): > Dynamic linker not initialised > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <http://www.haskell.org/ghc/reportabug>

1 0

Accessing the "original" names via GHC API
by Ranjit Jhala 25 Jan '17

25 Jan '17

Hi, I'm quite vexed trying to do the following. Suppose I have a file: ``` module Foo import qualified Data.Set as S baz :: S.Set Int baz = S.empty ``` My goal is to write a function tyconString :: TyCon -> String (perhaps with extra parameters) such that given the `TyCon` corresponding to `Set`, I get back the "original" name `S.Set`, or even `Data.Set.Set`. Everything I've tried, which is fiddling with different variants of `PprStyle`, end up giving me `Data.Set.Base.Set` Does anyone have a suggestion for how to proceed? Thanks! - Ranjit.

4 5