- Glasgow-haskell-users

Re: Why isn't this Overlapping?
by Anthony Clayden 18 Apr '17

18 Apr '17

> On Tue Apr 18 00:50:20 UTC 2017, Iavor Diatchki wrote: > > these two instances really should be rejected as they > violate the FD of the class: we can derive `TypeEq a a > True` using the first instance and `TypeEq a a False` > using the second one. Unfortunately, the check that we > are using to validate FDs when `UndecidableInstances` is > on, is not quite correct (relevant tickets are #9210 and > #10675 where there are similar examples). > Thanks Iavor, it was a propos those tickets I'm asking. See my comments on #10675 -- we'll have to agree to disagree on "not quite correct". (If you want to ban instance selecting on type equality, you'll make a lot of people grumpy.) My surprise here is why GHC doesn't complain about overlaps. (Separately from whether it's doing the right thing.) Here's another example [GHC 7.10] and here I agree the FunDep consistency is well broken, again needs UndecidableInstances: {-# LANGUAGE MultiParamTypeClasses, GADTs, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-} class C a b | a -> b where foo :: a -> b -> String instance C Int Bool where foo _ _ = "Bool called" {- So far so good: no bare typevars in instance head; don't need UndecidableInstances for that -} instance (b ~ Char) => C Int b where foo _ _ = "b ~ Char called" I can't write that instance head `C Int Char`. GHC complains inconsistent with FunDep [quite correct]. But I can call `foo (5 :: Int) 'c'` ==> "b ~ Char called". If I call `foo (5 :: Int) undefined` ==> GHC complains of overlaps. [I would say fair enough too, except ...] If I change the instance to instance {-# OVERLAPPABLE #-} (b ~ Char) => C Int b where .. Then `foo (5 :: Int) undefined` ==> "Bool called" So GHC both uses the FunDep to improve the type, and uses the improvement to select an instance; and yet seems blind to FunDep inconsistencies in the instance decls. AntC > > > On Sun, Apr 16, 2017 at 12:13 AM, Anthony Clayden wrote: > > > > --ghc 7.10 or 8.0.1 > > > > {-# LANGUAGE DataKinds, KindSignatures, GADTs, > > MultiParamTypeClasses, > > FunctionalDependencies, FlexibleInstances, > > UndecidableInstances, > > NoOverlappingInstances #-} > > > > class TypeEq a a' (b :: Bool) | a a' -> b > > > > instance (b ~ True) => TypeEq a a b > > instance (b ~ False) => TypeEq a a' b > > > > Those two instance heads are nearly identical, surely > > they overlap? > > And for a type-level type equality test, they must be > > unifiable. > > But GHC doesn't complain. > > > > If I take off the FunDep, then GHC complains. > > > > AFAICT none of those extensions imply Overlaps, > > but to be sure I've put NoOverlapping. > > > > > > AntC > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > >

1 0

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

25 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 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