- Glasgow-haskell-users

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

[ANNOUNCE] Glasgow Haskell Compiler 8.0.2 is available!
by Ben Gamari 19 Jan '17

19 Jan '17

=============================================== The Glasgow Haskell Compiler -- version 8.0.2 =============================================== The GHC team is happy to at last announce the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2/ This is the second release of the 8.0 series and fixes nearly two-hundred bugs. These include, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Compatibility with systems which use the gold linker * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. * #12757, which lead to broken runtime behavior and even crashes in the presence of primitive strings. * #12844, a type inference issue affecting partial type signatures. * A bump of the `directory` library, fixing buggy path canonicalization behavior (#12894). Unfortunately this required a major version bump in `directory` and minor bumps in several other libraries. * #12912, where use of the `select` system call would lead to runtime system failures with large numbers of open file handles. * #10635, wherein -Wredundant-constraints was included in the -Wall warning set A more detailed list of the changes included in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/8.0.2-notes.… Please note that this release breaks with our usual tendency to avoid major version bumps of core libraries in minor GHC releases by including an upgrade of the `directory` library to 1.3.0.0. Also note that, due to a rather serious bug (#13100) affecting Windows noticed late in the release cycle, the Windows binary distributions were produced using a slightly patched [2] source tree. Users compiling from source for Windows should be certain to include this patch in their build. This release is the result of six months of effort by the GHC development community. We'd like to thank everyone who has contributed code, bug reports, and feedback to this release. It's only due to their efforts that GHC remains a vibrant and exciting project. [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id… [2] http://downloads.haskell.org/~ghc/8.0.2/0001-SysTools-Revert-linker-flags-c… How to get it ~~~~~~~~~~~~~ Both the source tarball and binary distributions for a wide variety of platforms are available at, http://www.haskell.org/ghc/ Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, can be found on the GHC wiki http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 2

Re: Rewrite rules
by David Feuer 16 Jan '17

16 Jan '17

No. The part in quotes is the *name* of the rewrite rule, which is reported to the user when GHC is called with things like -ddump-rule-rewrites and is otherwise completely ignored. On Jan 16, 2017 4:09 AM, "Erik de Castro Lopo" <mle+hs(a)mega-nerd.com> wrote: Joachim Breitner wrote: > very little. The best one can do right now is to know enough about Core > and the inliner to predict when things are going to be inlined and when > not, what else can go wrong (wrappers maybe?), add the necessary > controls (`NOINLINE [0]` etc.), and then hope for the best. And track > down any instances of failed rewriting that you learn about. > > You might also be able to set up your code so that it fails (at > runtime, with error) if the desired rules did not fire. This would be > nicer if we had https://ghc.haskell.org/trac/ghc/ticket/9180. > > You can also ask for review if it is public code. Ok, I'm heading in this direction and then I figure out that the parser for the rewrite rules doesn't even reject obvious syntax errors. Say I have a data types: data Word128 = Word128 Word64 Word64 and inspired by the `fromIntegral` rules for Word64 I write: {-# RULES "fromIntegral/Word64->Word128" fromIntegral = \w64 -> Word128 0 w64 #-} all is fine and dandy. However if I introduce an obvious syntax error like reversing the `->`: {-# RULES "fromIntegral/Word64<-Word128" fromIntegral = \w64 -> Word128 0 w64 #-} I don't get any warning or anything. I've read the docs for rewrite rules: https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_ guide/glasgow_exts.html#rewrite-rules but they are rather sparse and again are very short on guarantees. Have I just managed to find myself a new project? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

1 0

Rewrite rules
by Erik de Castro Lopo 16 Jan '17

16 Jan '17

HI all, I'm having an look at rewrite rules, but something bugs me a little. How do I tell if my rewrite rules are firing or not? Even If I introduce deliberate errors in the function name that is being re-written I still don't get so much as a warning. Clues? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 4

Re: Derived Functor instance for void types
by Edward Kmett 16 Jan '17

16 Jan '17

"Preserving user bottoms" was found to be better behavior for us with Void as well back in the day. Evaluating such a term to get the bottom out is better than making up one that loses information for the user about precisely what bottom it is they had. We do so with absurd and the like for Void. This way if you map over a structure with errors at the leaves you get a new structure with those same errors at the leaves. *tl;dr* +1 from me. -Edward On Sun, Jan 15, 2017 at 11:00 PM, Kevin Cotrone <kevincotrone(a)gmail.com> wrote: > That seems to have a surprising strictness. > > I'm not sure if it would be the best idea to try and evaluate a type with > no inhabitants. > > On Sun, Jan 15, 2017 at 2:37 PM, David Feuer <david.feuer(a)gmail.com> > wrote: > >> Currently, if you write >> >> data V a deriving Functor >> >> GHC generates >> >> fmap _ _ = error "Void fmap" >> >> This seems quite unfortunate, because it loses potentially useful error >> information: >> >> fmap (+ 3) (error "Too many snozzcumbers!") >> >> throws "Void fmap", rather than the much more precise "Too many >> snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should >> double check that no one is opposed. >> >> David Feuer >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

1 0

Re: Derived Functor instance for void types
by David Feuer 16 Jan '17

16 Jan '17

I don't know what you mean. fmap for an uninhabited type is vacuously strict: its result is always _|_. On Sun, Jan 15, 2017 at 11:00 PM, Kevin Cotrone <kevincotrone(a)gmail.com> wrote: > That seems to have a surprising strictness. > > I'm not sure if it would be the best idea to try and evaluate a type with no > inhabitants. > > On Sun, Jan 15, 2017 at 2:37 PM, David Feuer <david.feuer(a)gmail.com> wrote: >> >> Currently, if you write >> >> data V a deriving Functor >> >> GHC generates >> >> fmap _ _ = error "Void fmap" >> >> This seems quite unfortunate, because it loses potentially useful error >> information: >> >> fmap (+ 3) (error "Too many snozzcumbers!") >> >> throws "Void fmap", rather than the much more precise "Too many >> snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should >> double check that no one is opposed. >> >> David Feuer >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >

1 0