From dominic at steinitz.org Fri Mar 3 16:49:20 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Fri, 3 Mar 2017 16:49:20 +0000 Subject: Fwd: accelerate-llvm problems References: <72624FAE-FC29-4020-9BA2-FEB1A68952A1@gmail.com> Message-ID: <9DCCA2AF-17F6-4A97-BE44-69F8BB3C7631@steinitz.org> > Begin forwarded message: > > From: Dominic Steinitz > Subject: Re: accelerate-llvm problems > Date: 3 March 2017 at 16:44:59 GMT > To: Trevor McDonell > Cc: GHC users , Ben Lippmeier > > 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 ' 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? > > >> On 21 Feb 2017, at 23:44, Trevor McDonell > 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 > 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 at 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 >> > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Sat Mar 4 04:30:20 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Sat, 4 Mar 2017 04:30:20 +0000 Subject: accelerate-llvm problems In-Reply-To: <72624FAE-FC29-4020-9BA2-FEB1A68952A1@gmail.com> References:

<72624FAE-FC29-4020-9BA2-FEB1A68952A1@gmail.com> Message-ID: <0ECEA3EA-25BB-4E3B-9595-4103D88D2151@steinitz.org> I created an issue here: https://github.com/bscarlet/llvm-general/issues/207 > On 3 Mar 2017, at 16:44, Dominic Steinitz 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 ' 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? > > >> On 21 Feb 2017, at 23:44, Trevor McDonell > 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 > 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 at 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 ) >> > >> > : >> > 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 >> > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Garrett.Morris at ed.ac.uk Thu Mar 9 17:53:33 2017 From: Garrett.Morris at ed.ac.uk (J. Garrett Morris) Date: Thu, 9 Mar 2017 17:53:33 +0000 Subject: GHC on Windows 10 15019+ Message-ID: 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. From tamar at zhox.com Sat Mar 11 09:26:18 2017 From: tamar at zhox.com (Tamar Christina) Date: Sat, 11 Mar 2017 09:26:18 +0000 Subject: GHC on Windows 10 15019+ Message-ID: <15abcb0aa46.107b0c5cd116624.4057594380136879987@zhox.com> 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 From qdunkan at gmail.com Tue Mar 14 08:28:24 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Tue, 14 Mar 2017 01:28:24 -0700 Subject: warn-identities from newtype deriving Message-ID: 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: : 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 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. From claude at mathr.co.uk Mon Mar 20 21:54:16 2017 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Mon, 20 Mar 2017 21:54:16 +0000 Subject: add constraint to the context of the RULE Message-ID: <3b2b9595-936a-63dc-807f-7a6a01b4dc9e@mathr.co.uk> 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 From david.feuer at gmail.com Tue Mar 21 20:34:20 2017 From: david.feuer at gmail.com (David Feuer) Date: Tue, 21 Mar 2017 16:34:20 -0400 Subject: DeriveFoldable treatment of tuples is surprising Message-ID: 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 From jake.mcarthur at gmail.com Tue Mar 21 21:05:19 2017 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Tue, 21 Mar 2017 21:05:19 +0000 Subject: DeriveFoldable treatment of tuples is surprising In-Reply-To: References: Message-ID: I think it's a question of what one considers consistent. Is it more consistent to treat tuples as transparent and consider every component with type `a`, or is it more consistent to treat tuples as opaque and reuse the existing Foldable instance for tuples even if it might cause a compile time error? On Tue, Mar 21, 2017, 4:34 PM 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 > > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Mar 21 21:11:39 2017 From: david.feuer at gmail.com (David Feuer) Date: Tue, 21 Mar 2017 17:11:39 -0400 Subject: DeriveFoldable treatment of tuples is surprising In-Reply-To: References:

Message-ID: The point is that there are two reasonable ways to do it, and the deriving mechanism, as a rule, does not make choices between reasonable alternatives. On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur wrote: > I think it's a question of what one considers consistent. Is it more > consistent to treat tuples as transparent and consider every component with > type `a`, or is it more consistent to treat tuples as opaque and reuse the > existing Foldable instance for tuples even if it might cause a compile time > error? > > > On Tue, Mar 21, 2017, 4:34 PM 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 >> >> 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 >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From ekmett at gmail.com Tue Mar 21 21:29:20 2017 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 21 Mar 2017 17:29:20 -0400 Subject: DeriveFoldable treatment of tuples is surprising In-Reply-To: References:

Message-ID: As I recall, Richard Eisenberg has been pushing, off and on, for us to get a better vocabulary to specify "how" something is derived, via DeriveAnyClass, generalized newtype deriving, DeriveFoldable, etc. 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 and there is a fair bit of user code for things like vector types that do things like newtype V3 a = V3 (a,a,a,a) replacing that with a data type isn't without cost because now converting back and forth between that and a tuple could no longer be done for zero cost with coercions. This style of code is more common among the ML-turned-haskeller crowd, whom -- in my experience -- tend to think of it as just giving the constructor paren around its arguments rather than as a tuple. Destroying Foldable for that and making working code not work just for users to have to manually specify multiple tedious instances that should be easily derivable shouldn't be a thing we do lightly. DeriveFunctor doesn't consider that functors involved may be contravariant either. DeriveFoo generally does something that is a best effort. I'm more inclined to leave it on the list of things that DeriveFoo does differently than GND, and as yet another argument pushing us to find a better vocabulary for talking about deriving. -Edward On Tue, Mar 21, 2017 at 5:11 PM, David Feuer wrote: > The point is that there are two reasonable ways to do it, and the > deriving mechanism, as a rule, does not make choices between > reasonable alternatives. > > On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur > wrote: > > I think it's a question of what one considers consistent. Is it more > > consistent to treat tuples as transparent and consider every component > with > > type `a`, or is it more consistent to treat tuples as opaque and reuse > the > > existing Foldable instance for tuples even if it might cause a compile > time > > error? > > > > > > On Tue, Mar 21, 2017, 4:34 PM 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 > >> > >> 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 > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Wed Mar 22 08:12:27 2017 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 22 Mar 2017 09:12:27 +0100 Subject: DeriveFoldable treatment of tuples is surprising In-Reply-To: References:

Message-ID: 2017-03-21 22:29 GMT+01:00 Edward Kmett : > [... 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. [...] > OTOH, the current behavior contradicts my intuition that wrapping a type into data/newtype plus using the deriving machinery is basically a no-op (modulo bottoms etc.). When I e.g. wrap a type t, I would be very surprised if the Eq/Ord instances of the wrapped type would behave differently than the one on t. I know that this is very handwavy argument, but I think the current behavior is *very* surprising. Somehow the current behavior seems to be incompatible with the FTP, where pairs are given a special treatment (if that't the right/intuitive choice is a completely different topic, though). Given the fact that "deriving Foldable" is quite old and therefore hard to change, I would at least suggest a big, fat warning in the documentation, including various examples where intuition and implementation do not necessarily meet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Mar 22 09:38:58 2017 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 22 Mar 2017 09:38:58 +0000 Subject: DeriveFoldable treatment of tuples is surprising In-Reply-To: References:

Message-ID: > there is a fair bit of user code for things like vector types that do things like newtype V3 a = V3 (a,a,a,a) ^ 1 2 3 4(!?) Oh boy, I sure hope not ;) On Wed, Mar 22, 2017 at 8:14 AM Sven Panne wrote: > 2017-03-21 22:29 GMT+01:00 Edward Kmett : > > [... 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. [...] > > > OTOH, the current behavior contradicts my intuition that wrapping a type > into data/newtype plus using the deriving machinery is basically a no-op > (modulo bottoms etc.). When I e.g. wrap a type t, I would be very surprised > if the Eq/Ord instances of the wrapped type would behave differently than > the one on t. I know that this is very handwavy argument, but I think the > current behavior is *very* surprising. > > Somehow the current behavior seems to be incompatible with the FTP, where > pairs are given a special treatment (if that't the right/intuitive choice > is a completely different topic, though). > > Given the fact that "deriving Foldable" is quite old and therefore hard to > change, I would at least suggest a big, fat warning in the documentation, > including various examples where intuition and implementation do not > necessarily meet. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From twanvl at gmail.com Wed Mar 22 13:54:05 2017 From: twanvl at gmail.com (Twan van Laarhoven) Date: Wed, 22 Mar 2017 14:54:05 +0100 Subject: DeriveFoldable treatment of tuples is surprising In-Reply-To: References: Message-ID: <66a3d116-6aaa-282f-4466-1bd20402b64e@gmail.com> 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 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 Twan From ben.franksen at online.de Wed Mar 22 22:59:17 2017 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 22 Mar 2017 23:59:17 +0100 Subject: WARNING in hptSomeThingsBelowUs Message-ID: 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 From qdunkan at gmail.com Wed Mar 22 23:43:08 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 22 Mar 2017 16:43:08 -0700 Subject: WARNING in hptSomeThingsBelowUs In-Reply-To: References: Message-ID: I've been seeing this since 6.12. I brought it up 7 (!) years ago, but unfortunately it doesn't look like I filed a bug as Simon requested. I probably failed to reproduce easily, and then forgot. But it still definitely happens. On Wed, Mar 22, 2017 at 3:59 PM, Ben Franksen wrote: > 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 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From ben.franksen at online.de Wed Mar 22 23:51:40 2017 From: ben.franksen at online.de (Ben Franksen) Date: Thu, 23 Mar 2017 00:51:40 +0100 Subject: WARNING in hptSomeThingsBelowUs In-Reply-To: References:

Message-ID: I can provide a test case (the darcs darcs repo) where I have just seen this for the second time. Am 23.03.2017 um 00:43 schrieb Evan Laforge: > I've been seeing this since 6.12. I brought it up 7 (!) years ago, > but unfortunately it doesn't look like I filed a bug as Simon > requested. I probably failed to reproduce easily, and then forgot. > But it still definitely happens. > > On Wed, Mar 22, 2017 at 3:59 PM, Ben Franksen wrote: >> 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. From anthony_clayden at clear.net.nz Sat Mar 25 03:08:36 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 25 Mar 2017 16:08:36 +1300 Subject: DeriveFoldable treatment of tuples is surprising Message-ID: <58d5df34.26b.41f3.21322@clear.net.nz> > 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 From ch.martin at gmail.com Fri Mar 31 14:35:52 2017 From: ch.martin at gmail.com (Chris Martin) Date: Fri, 31 Mar 2017 14:35:52 +0000 Subject: Alternative to importing GHC.TypeLits? Message-ID: 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_exts.html?highlight=typelits#type-level-literals GHC.TypeLits: https://www.stackage.org/haddock/lts-8.5/base-4.9.1.0/GHC-TypeLits.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Mar 31 16:44:30 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 31 Mar 2017 09:44:30 -0700 Subject: Alternative to importing GHC.TypeLits? In-Reply-To: References: Message-ID: Hi, the initial plan was that `GHC.TypeLits` should provide just the basic functionality, and later other libraries would be build to provide more convenient functions for specific applications. I don't know of any such convenience libraries, so at present, people just import `GHC.TypeLits` directly. -Iavor On Fri, Mar 31, 2017 at 7:35 AM, Chris Martin wrote: > 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_exts.html?highlight=typelits#type-level-literals > > GHC.TypeLits: https://www.stackage.org/haddock/lts-8.5/base-4.9.1.0/ > GHC-TypeLits.html > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: