- Glasgow-haskell-users

Inlining phase control for derived methods?
by Conal Elliott 17 Dec '16

17 Dec '16

Is it possible to control when *derived* methods get inlined, say postponing to the last simplifier phase? I'm thinking in particular of instances derived via GeneralizedNewtypeDeriving. -- Conal

1 0

bus error in Integer calculations
by Geraint Jones 15 Dec '16

15 Dec '16

I have this little demo which I use for sixth formers which includes calculating in fairly rapid order the sum of the digits of the 10^9th Fibonacci number. (I haven't got enough physical memory to do the same for the 10^10th number without thrashing...) It fell over on a flashy new macbook I was going to use for the presentation the other day; indeed I found I couldn't even calculate the sum of the digits of the 10^6th number. I've reduced the problem to calculating numbers as large as 2^10000000 (as an Integer, of course), which works on all the ghci 7.8.4 implementations I can find on various machines around the department, but which falls over on the 8.0.1 implementation on my macbook. 2^1000000 is fine, but 2^10000000 causes a bus error which may well be a stack overflow in libHSinteger-gmp-1.0.0.1-ghc8.0.1.dylib I don't seem to have easy access to 8.0.1 elsewhere or other implementations on a mac. Does anyone have a handle on whether this is a problem with the sizing of the mac implementation or whether it is a pervasive 8.0.1 problem? Either way, it doesn't seem friendly that it manifests as an uncaught bus error.

3 2

GHC API: memory usage of loaded modules
by Evan Laforge 15 Dec '16

15 Dec '16

I have a program that uses the GHC API to provide a REPL. It winds up taking up 200mb in RAM, as measured by GHC.Stats.currentBytesUsed, but without the GHC API it's 5mb. If I turn on verbose, I can see that GHC is loading 255 modules, all loaded binary ("skipping M ( M.hs, M.hs.o )") except the toplevel, and the memory use is zooming up as it loads them. I expect some memory usage from loading modules, but 195mb seems like a lot. If I do a 'du' on the entire obj directory (which has 401 *.hs.o files... the REPL doesn't expose everything), it's only 76mb on disk. How do loaded modules wind up consuming space, and is there any way to use less space? The thing is, all those loaded modules are part of the application itself, so presumably they've already been linked into the binary and loaded into memory. The ideal would be that I could somehow reuse that. I imagine that I could by writing my own haskell interpreter and making a big symbol table of all the callable functions, but I'd rather not write my own interpreter if I can use an existing one!

3 6

Stack traces in ghci
by Dominic Steinitz 08 Dec '16

08 Dec '16

I am trying to debug a package in which there is a divide by 0 error and attempting to use Simon Marlow’s stack traces: https://simonmar.github.io/posts/2016-02-12-Stack-traces-in-GHCi.html. However ghci is complaining about missing symbols. What do I need to add to the command line to coax ghci into giving me a stack trace? > ~/Dropbox/Private/Stochastic/demo $ ghci -fexternal-interpreter -prof fe-handling-example.o -i../../monad-bayes/src -package-db=.cabal-sandbox/x86_64-osx-ghc-8.0.1-packages.conf.d > GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help > Prelude> :l app/Main.hs > [ 1 of 16] Compiling Control.Monad.Bayes.LogDomain ( ../../monad-bayes/src/Control/Monad/Bayes/LogDomain.hs, interpreted ) > [ 2 of 16] Compiling Control.Monad.Bayes.Primitive ( ../../monad-bayes/src/Control/Monad/Bayes/Primitive.hs, interpreted ) > [ 3 of 16] Compiling Control.Monad.Bayes.Class ( ../../monad-bayes/src/Control/Monad/Bayes/Class.hs, interpreted ) > [ 4 of 16] Compiling Control.Monad.Bayes.Sampler ( ../../monad-bayes/src/Control/Monad/Bayes/Sampler.hs, interpreted ) > [ 5 of 16] Compiling Control.Monad.Bayes.Sequential ( ../../monad-bayes/src/Control/Monad/Bayes/Sequential.hs, interpreted ) > [ 6 of 16] Compiling Control.Monad.Bayes.Prior ( ../../monad-bayes/src/Control/Monad/Bayes/Prior.hs, interpreted ) > [ 7 of 16] Compiling Control.Monad.Bayes.Rejection ( ../../monad-bayes/src/Control/Monad/Bayes/Rejection.hs, interpreted ) > [ 8 of 16] Compiling Control.Monad.Bayes.Weighted ( ../../monad-bayes/src/Control/Monad/Bayes/Weighted.hs, interpreted ) > [ 9 of 16] Compiling Control.Monad.Bayes.Population ( ../../monad-bayes/src/Control/Monad/Bayes/Population.hs, interpreted ) > [10 of 16] Compiling Control.Monad.Bayes.Deterministic ( ../../monad-bayes/src/Control/Monad/Bayes/Deterministic.hs, interpreted ) > [11 of 16] Compiling Control.Monad.Bayes.Conditional ( ../../monad-bayes/src/Control/Monad/Bayes/Conditional.hs, interpreted ) > [12 of 16] Compiling Control.Monad.Bayes.Dist ( ../../monad-bayes/src/Control/Monad/Bayes/Dist.hs, interpreted ) > [13 of 16] Compiling Control.Monad.Bayes.Coprimitive ( ../../monad-bayes/src/Control/Monad/Bayes/Coprimitive.hs, interpreted ) > [14 of 16] Compiling Control.Monad.Bayes.Trace ( ../../monad-bayes/src/Control/Monad/Bayes/Trace.hs, interpreted ) > [15 of 16] Compiling Control.Monad.Bayes.Inference ( ../../monad-bayes/src/Control/Monad/Bayes/Inference.hs, interpreted ) > [16 of 16] Compiling Main ( app/Main.hs, interpreted ) > > app/Main.hs:92:7: warning: [-Wunused-matches] > Defined but not used: ‘a’ > > app/Main.hs:92:9: warning: [-Wunused-matches] > Defined but not used: ‘prevP’ > > app/Main.hs:92:15: warning: [-Wunused-matches] > Defined but not used: ‘prevZ’ > > app/Main.hs:106:5: warning: [-Wunused-do-bind] > A do-notation statement discarded a result of type ‘GHC.Prim.Any’ > Suppress this warning by saying > ‘_ <- ($) > error (++) "You are here " (++) show state (++) " " show p_obs’ > Ok, modules loaded: Main, Control.Monad.Bayes.LogDomain, Control.Monad.Bayes.Primitive, Control.Monad.Bayes.Class, Control.Monad.Bayes.Population, Control.Monad.Bayes.Conditional, Control.Monad.Bayes.Inference, Control.Monad.Bayes.Sampler, Control.Monad.Bayes.Rejection, Control.Monad.Bayes.Weighted, Control.Monad.Bayes.Sequential, Control.Monad.Bayes.Trace, Control.Monad.Bayes.Dist, Control.Monad.Bayes.Prior, Control.Monad.Bayes.Deterministic, Control.Monad.Bayes.Coprimitive. > *Main> main > ghc-iserv-prof: > lookupSymbol failed in relocateSection (relocate external) > /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx-ghc-8.0.1/hmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown symbol `___ieee_divdc3' > ghc-iserv-prof: Could not on-demand load symbol '_vectorScan' > > ghc-iserv-prof: > lookupSymbol failed in relocateSection (relocate external) > /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx-ghc-8.0.1/hmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown symbol `_vectorScan' > ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziVectorizzed_constantAux_closure' > > ghc-iserv-prof: > lookupSymbol failed in relocateSection (relocate external) > /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx-ghc-8.0.1/hmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown symbol `_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziVectorizzed_constantAux_closure' > ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziMatrix_Matrix_con_info' > > ghc-iserv-prof: > lookupSymbol failed in relocateSection (relocate external) > /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx-ghc-8.0.1/hmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown symbol `_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziMatrix_Matrix_con_info' > ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziElement_zgzl_info' > > ghc-iserv-prof: > lookupSymbol failed in relocateSection (relocate external) > /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx-ghc-8.0.1/hmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown symbol `_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziElement_zgzl_info' > ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziUtil_zdfIndexableVectorDouble_closure' > > > ByteCodeLink.lookupCE > During interactive linking, GHCi couldn't find the following symbol: > hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziUtil_zdfIndexableVectorDouble_closure > This may be due to you not asking GHCi to load extra object files, > archives or DLLs needed by your current session. Restart GHCi, specifying > the missing library using the -L/path/to/object/dir and -lmissinglibname > flags, or simply by naming the relevant files on the GHCi command line. > Alternatively, this link failure might indicate a bug in GHCi. > If you suspect the latter, please send a bug report to: > glasgow-haskell-bugs(a)haskell.org Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

3 3

Floating Point Exceptions
by Dominic Steinitz 07 Dec '16

07 Dec '16

Hello again, I removed my dependency on hmatrix and enabled floating point exceptions via `feenableexcept` hoping to get a call stack showing me where the exception was being raised but alas all I get is > *Main> main > ghc: ghc-iserv terminated (-8) > Leaving GHCi. My googling didn’t turn up much but as far as I can tell ghc does *not* handle sigfpe (googling "haskell sigfpe” turns up blog posts on Haskell by someone called “sigfpe”). I think it would be jolly useful to be able to get stack traces of floating point exceptions. How much work would this be? I’d be happy to have a go at it if someone could provide help and guidance. There seems to have been some discussion of it on the ghc-devs mailing list in September (https://mail.haskell.org/pipermail/ghc-devs/2016-September/date.html) but not much in the way of write up. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

2 1

"instrumenting" functions
by Ranjit Jhala 01 Dec '16

01 Dec '16

Hi all, Given a module with top-level (functions) f1 ... fn, I would like to generate/compile an "instrumented" version where, say, each function prints the string "hello", every time it is called. Can anyone suggest some ways of doing this? One option is a core-to-core transform with an unsafePerformIO (print "hello") stuck into the appropriate places. But perhaps there are better ways? Ideally I'd like to instrument each "App" to log every function application. Are other libraries or tools that use the GHC API to do this sort of thing? Thanks in advance! Ranjit.

1 0

[ANNOUNCE] GHC 8.0.2 release candidate 1
by Ben Gamari 29 Nov '16

29 Nov '16

Hello everyone, The GHC team is happy to (finally!) announce the first candiate of 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-rc1/ This is the first of what will hopefully be only two release candidates leading up the final 8.0.2 release. This release will fix a number bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * 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. Unfortunately there is one known bug (#12757) which can result in runtime crashes which is still lurking in -rc1. This will be fixed in -rc2, which will be released in about a week. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id…

3 5

RE: Getting rid of -XImpredicativeTypes
by Simon Peyton Jones 26 Sep '16

26 Sep '16

1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) Yes, they’d disappear. 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? It’s just a swamp. I have tried multiple times to fix ImpredicativeTypes, and failed every time. Which is not to say that someone shouldn’t try again, with new thinking. Simon From: Dan Doel [mailto:dan.doel@gmail.com] Sent: 26 September 2016 00:54 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: ghc-users(a)haskell.org; ghc-devs(a)haskell.org Subject: Re: Getting rid of -XImpredicativeTypes I don't use the extension, because it's more pleasant to use newtypes with polymorphic contents. But here are some questions: 1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who was working on it, but I think when I mentioned it in the context of something else, you didn't seem to be aware of it. I guess it's safe to say that nothing ever came of it, at least inasmuch as no one ever showed you their proposal for a properly functioning ImpredicativeTypes? Anyhow, if it can't be fixed, I think not having the extension is superior to its current state. And really, I think even if fixing it were on the roadmap, it'd be better to get rid of it until it were actually fixed. -- Dan On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 0

FW: Getting rid of -XImpredicativeTypes
by Simon Peyton Jones 26 Sep '16

26 Sep '16

Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter… if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I’m on a plane, so I’m going to at least start with an email. Simon

1 0

Type families in kind signatures with TypeInType
by David Menendez 23 Sep '16

23 Sep '16

Should the code below work in GHC 8.0.1? {-# LANGUAGE TypeInType, TypeFamilies #-} import Data.Kind (Type) type family K t :: Type type family T t :: K t -> Type data List type instance K List = Type type instance T List = [] Right now, I get an error like this one: min.hs:12:24: error: • Expected kind ‘K List -> Type’, but ‘[]’ has kind ‘* -> *’ • In the type ‘[]’ In the type instance declaration for ‘T’ which is puzzling, since K List -> Type and * -> * should be the same. Obviously, TypeInType is experimental and incomplete. I’m just wondering if this sort of thing is expected to work, or if I’m doing something not yet supported or never to be supported In particular, the kind signature for T is forall t -> K t -> Type, which looks like DependentHaskell. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 4