March 2017 - Glasgow-haskell-users

Alternative to importing GHC.TypeLits?
by Chris Martin 31 Mar '17

31 Mar '17

The GHC manual gives code examples that import GHC.TypeLits. The documentation on that module seems to request that users /not/ import it ... > This module is an internal GHC module. [...] The programmer interface for working with type-level naturals should be defined in a separate library. ... although I'm not sure what "what be" means here. Does that mean it's a to-do item, and that there will eventually be a separate library, but that we should use this "internal" library directly for now? --- GHC manual: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… GHC.TypeLits: https://www.stackage.org/haddock/lts-8.5/base-4.9.1.0/GHC-TypeLits.html

2 1

Re: DeriveFoldable treatment of tuples is surprising
by Anthony Clayden 24 Mar '17

24 Mar '17

> On Wed Mar 22 13:54:05 UTC 2017, Twan van Laarhoven wrote: >> On 2017-03-21 21:34, David Feuer wrote: >> This seems much too weird: >> >> *> :set -XDeriveFoldable >> *> data Foo a = Foo ((a,a),a) deriving Foldable >> *> length ((1,1),1) >> 1 >> *> length $ Foo ((1,1),1) >> 3 Hmm. *> length $ Just ((1, 1), 1) 1 *> length $ Just (1, 1) 1 *> length (1, 1) 1 > This is not unique to tuples, consider: > > :set -XDeriveFoldable > > data Foo a = Foo [[a]] deriving Foldable > > length [[1,2]] > 1 > > length $ Foo [[1,2]] > 2 > length $ Just [[1, 2]] 1 Does the behaviour of other methods within Foldable seem surprising for DeriveFoldable Foo a = Foo ((a, a), a)? Did the FTP change touch DeriveFoldable? (Silly question, yes it must have: `length` didn't used to be in Foldable.) > On Tue Mar 21 21:29:20 UTC 2017, Edward Kmett wrote: > In general I think the current behavior is the least surprising as it > "walks all the a's it can" and is the only definition compatible with > further extension with Traversable. Right now there are no instances > provided by base that violate the "walk all the a's" intuition ?? Are there instances in base where the `a` appears more than once on RHS? I can see only List and Array. How would I have formed that "walk all the a's" intuition? (For most of the Prelude instances, `length`s result is hard-coded as 0 or 1.) *> length (((1, 2), 3) :: Num a => ((a, a), a)) 1 Doesn't seem to "walk all the a's" there. I find pretty much all of these results surprising. (Admittedly for different reasons in different cases.) I think this is a good reason `length` should not be in Foldable. "lengthiness" just doesn't fit the abstraction. AntC

1 0

WARNING in hptSomeThingsBelowUs
by Ben Franksen 22 Mar '17

22 Mar '17

This is what I get after removing a file from the working tree and also from the cabal file for the project and then rebuild. WARNING in hptSomeThingsBelowUs missing module Darcs.Util.Environment Probable cause: out-of-date interface files I am using cabal new-build. Cabal folks tell me this is a ghc problem. I am using ghc-7.10.3. Cheers Ben

2 2

DeriveFoldable treatment of tuples is surprising
by David Feuer 22 Mar '17

22 Mar '17

This seems much too weird: *> :set -XDeriveFoldable *> data Foo a = Foo ((a,a),a) deriving Foldable *> length ((1,1),1) 1 *> length $ Foo ((1,1),1) 3 I've opened Trac #13465 [*] for this. As I write there, I think the right thing is to refuse to derive Foldable for a type whose Foldable instance would currently fold over components of a tuple other than the last one. I could go either way on Traversable instances. One could argue that since all relevant components *must* be traversed, we should just go ahead and do that. Or one could argue that we should be consistent with Foldable and refuse to derive it. What do you all think? [*] https://ghc.haskell.org/trac/ghc/ticket/13465

6 6

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 03 Mar '17

03 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