From jhala at cs.ucsd.edu Thu Dec 1 16:56:07 2016
From: jhala at cs.ucsd.edu (Ranjit Jhala)
Date: Thu, 1 Dec 2016 08:56:07 -0800
Subject: "instrumenting" functions
Message-ID:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dominic at steinitz.org Mon Dec 5 12:20:30 2016
From: dominic at steinitz.org (Dominic Steinitz)
Date: Mon, 5 Dec 2016 12:20:30 +0000
Subject: Stack traces in ghci
Message-ID: <51EDE7A4-870A-4403-846A-CFA47E1B9FB8@steinitz.org>
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 at haskell.org
Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com
From marlowsd at gmail.com Wed Dec 7 13:52:03 2016
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 7 Dec 2016 13:52:03 +0000
Subject: Stack traces in ghci
In-Reply-To: <51EDE7A4-870A-4403-846A-CFA47E1B9FB8@steinitz.org>
References: <51EDE7A4-870A-4403-846A-CFA47E1B9FB8@steinitz.org>
Message-ID:
Hi Dominic - this looks like a problem with loading hmatrix into GHCi.
Does it load without -prof and -fexternal-interpreter? How about with just
-fexternal-interpreter?
Cheers
SImon
On 5 December 2016 at 12:20, Dominic Steinitz wrote:
> 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 at haskell.org
>
>
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> _______________________________________________
> 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 dominic at steinitz.org Wed Dec 7 16:37:10 2016
From: dominic at steinitz.org (dominic at steinitz.org)
Date: Wed, 7 Dec 2016 16:37:10 +0000
Subject: Stack traces in ghci
In-Reply-To:
References: <51EDE7A4-870A-4403-846A-CFA47E1B9FB8@steinitz.org>
Message-ID: <64BA9CB8-CD5D-4D02-85ED-80B029E19920@steinitz.org>
Hi Simon,
Thanks for getting back.
1. Without -prof and -fexternal-interpreter, the program runs fine.
2. With just -prof, the program runs fine.
3. With just -fexternal-interpreter, I get the error below.
Dominic.
> On 7 Dec 2016, at 13:52, Simon Marlow wrote:
>
> Hi Dominic - this looks like a problem with loading hmatrix into GHCi. Does it load without -prof and -fexternal-interpreter? How about with just -fexternal-interpreter?
>
> Cheers
> SImon
>
> On 5 December 2016 at 12:20, Dominic Steinitz > wrote:
> 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 at haskell.org
>
>
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dominic at steinitz.org Wed Dec 7 16:51:49 2016
From: dominic at steinitz.org (Dominic Steinitz)
Date: Wed, 7 Dec 2016 16:51:49 +0000
Subject: Floating Point Exceptions
Message-ID: <32CB1DCD-3549-427B-86F9-53E2067748E9@steinitz.org>
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 at steinitz.org
http://idontgetoutmuch.wordpress.com
From carter.schonwald at gmail.com Wed Dec 7 21:07:38 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 07 Dec 2016 21:07:38 +0000
Subject: Floating Point Exceptions
In-Reply-To: <32CB1DCD-3549-427B-86F9-53E2067748E9@steinitz.org>
References: <32CB1DCD-3549-427B-86F9-53E2067748E9@steinitz.org>
Message-ID:
Adding sigfpe handling doesn't have a writeupnyet because it's on my
holiday project queue and the specifics of doing it nicely depend somewhat
on the target architecture.
If you want to get good errors in the mean time, register a sigfpe signal
handler at the top level and invoke a smidge of c code to get info.
Granted this doesn't give you a stack trace ...
On Wed, Dec 7, 2016 at 11:52 AM Dominic Steinitz
wrote:
> 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 at steinitz.org
>
> http://idontgetoutmuch.wordpress.com
>
>
>
> _______________________________________________
>
> 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 marlowsd at gmail.com Thu Dec 8 13:20:26 2016
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 8 Dec 2016 13:20:26 +0000
Subject: Stack traces in ghci
In-Reply-To: <64BA9CB8-CD5D-4D02-85ED-80B029E19920@steinitz.org>
References: <51EDE7A4-870A-4403-846A-CFA47E1B9FB8@steinitz.org>
<64BA9CB8-CD5D-4D02-85ED-80B029E19920@steinitz.org>
Message-ID:
I created a ticket: https://ghc.haskell.org/trac/ghc/ticket/12946
On 7 December 2016 at 16:37, wrote:
> Hi Simon,
>
> Thanks for getting back.
>
> 1. Without -prof and -fexternal-interpreter, the program runs fine.
>
> 2. With just -prof, the program runs fine.
>
> 3. With just -fexternal-interpreter, I get the error below.
>
> Dominic.
>
> On 7 Dec 2016, at 13:52, Simon Marlow wrote:
>
> Hi Dominic - this looks like a problem with loading hmatrix into GHCi.
> Does it load without -prof and -fexternal-interpreter? How about with just
> -fexternal-interpreter?
>
> Cheers
> SImon
>
> On 5 December 2016 at 12:20, Dominic Steinitz
> wrote:
>
>> 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-7aYEqJARQEvKY
>> NyM4UGAPZ/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-7aYEqJARQEvKY
>> NyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown
>> symbol `_vectorScan'
>> > ghc-iserv-prof: Could not on-demand load symbol
>> '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziVe
>> ctorizzed_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-7aYEqJARQEvKY
>> NyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown
>> symbol `_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziVe
>> ctorizzed_constantAux_closure'
>> > ghc-iserv-prof: Could not on-demand load symbol
>> '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziMa
>> trix_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-7aYEqJARQEvKY
>> NyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown
>> symbol `_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziMa
>> trix_Matrix_con_info'
>> > ghc-iserv-prof: Could not on-demand load symbol
>> '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziEl
>> ement_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-7aYEqJARQEvKY
>> NyM4UGAPZ/libHShmatrix-0.18.0.0-7aYEqJARQEvKYNyM4UGAPZ_p.a: unknown
>> symbol `_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziEl
>> ement_zgzl_info'
>> > ghc-iserv-prof: Could not on-demand load symbol
>> '_hmatrixzm0zi18zi0zi0zm7aYEqJARQEvKYNyM4UGAPZZ_InternalziUt
>> il_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 at haskell.org
>>
>>
>>
>> Dominic Steinitz
>> dominic at steinitz.org
>> http://idontgetoutmuch.wordpress.com
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Geraint.Jones at wolfson.ox.ac.uk Thu Dec 8 23:43:08 2016
From: Geraint.Jones at wolfson.ox.ac.uk (Geraint Jones)
Date: Thu, 8 Dec 2016 23:43:08 GMT
Subject: bus error in Integer calculations
Message-ID: <201612082343.uB8Nh8gK008815@linux1.cs.ox.ac.uk>
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.
From clintonmead at gmail.com Fri Dec 9 01:36:28 2016
From: clintonmead at gmail.com (Clinton Mead)
Date: Fri, 9 Dec 2016 12:36:28 +1100
Subject: bus error in Integer calculations
In-Reply-To: <201612082343.uB8Nh8gK008815@linux1.cs.ox.ac.uk>
References: <201612082343.uB8Nh8gK008815@linux1.cs.ox.ac.uk>
Message-ID:
I'm not a GHC developer but I think you should report a bug here:
https://ghc.haskell.org/trac/ghc/wiki/ReportABug
I've done it a couple of times and if you provide a reproducible test case
it will usually get looked at at some point.
Managing all the bugs on a mailing list would be a nightmare. If you're
worried it might not actually be a bug well they can always just close it.
On Fri, Dec 9, 2016 at 10:43 AM, Geraint Jones <
Geraint.Jones at wolfson.ox.ac.uk> wrote:
> 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.
> _______________________________________________
> 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 george.colpitts at gmail.com Sun Dec 11 15:24:17 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 11 Dec 2016 15:24:17 +0000
Subject: GHC rewrite rules for class operations & laws
In-Reply-To:
References:
Message-ID:
Do you want me to add a task ticket to remove this restriction that rewrite
rules can't be used for class methods?
On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via
Glasgow-haskell-users wrote:
> Conal
>
>
>
> Is it possible to apply GHC rewrite rules to class methods?
>
>
>
> Not currently. See https://ghc.haskell.org/trac/ghc/ticket/11688, esp
> comment:7 which gives links to similar examples.
> https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more
> background.
>
>
>
> It’d be great if someone wanted to think through all this.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 17 November 2016 16:40
> *To:* glasgow-haskell-users at haskell.org
> *Subject:* GHC rewrite rules for class operations & laws
>
>
>
> Is it possible to apply GHC rewrite rules to class methods? From what I’ve
> read and seen, class methods get eliminated early by
> automatically-generated rules. Is there really no way to postpone such
> inlining until a later simplifier stage? The GHC Users Guide docs say no
> ,
> and suggests instead giving a duplicate vocabulary with somewhat awkward
> names for class methods. I’ve not seen this practice in libraries. I gather
> that we cannot therefore use class laws as optimizations in the form of
> rewrite rules, which seems a terrible loss.
>
> In Control.Category and Control.Arrow, I see rules for class laws but
> also header comments saying “The RULES for the methods of class Arrow may
> never fire e.g. compose/arr; see Trac #10528”.
>
> I’d appreciate a reality check about my conclusions as well as any
> strategies for using class laws in optimization.
>
> Thanks, -- Conal
> _______________________________________________
> 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 qdunkan at gmail.com Tue Dec 13 18:21:48 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 13 Dec 2016 10:21:48 -0800
Subject: GHC API: memory usage of loaded modules
In-Reply-To:
References:
Message-ID:
Sorry about the delay, I got distracted by an unrelated memory leak.
On Tue, Nov 29, 2016 at 9:35 AM, Reid Barton wrote:
> You'd probably find that you also want to, for example, type check the
> expressions that you are interpreting. The information needed to do so
> is not contained in your executable at all; it's in the .hi files that
> were built alongside your program and its dependencies, and the ones
> that came with the libraries bundled into GHC. I assume the in-memory
> representation of these interface files is not very efficient, and
> they probably account for a lot of the space usage of your program.
That's true, but the .hi files on disk take up about 20k of that 76mb.
If the .o files are loaded basically directly as binary, then that
would mean 20k of .hi files turn into around 124mb in memory, which is
quite an expansion. But then there's all of the libraries I use and
then all their libraries... perhaps those need to be loaded too? If
so, there is more than I'm counting. I'm not sure how to count those,
since they're not included in the "upsweep" log msgs when you do a
GHC.load.
ghci itself takes about 200mb when it loads all that stuff, so I
imagine the memory use is "working as intended", not me just using the
API wrong.
> I'm not sure offhand, but perhaps using -fignore-interface-pragmas
> when you invoke the GHC API would reduce the amount of space used
> while loading interface files, and if you're using the bytecode
> interpreter then you probably don't care about any of the information
> it will discard (which mostly has to do with optimizations).
I tried it, and I recall at the time it helped, but now it's being
exactly the same, whether I try with ghci or my own GHC API using
program. E.g. I have:
memory_used :: IO Bytes
memory_used = do
System.Mem.performMajorGC
stats <- GHC.Stats.getGCStats
return $ Bytes $ fromIntegral $ GHC.Stats.currentBytesUsed stats
in a module that loads a lot of stuff. When I run that with ghci or
ghci -fignore-interface-pragmas, memory use is about the same.
> If you build your executable dynamically then the GHC API should also
> reuse the same shared libraries and executable image rather than
> loading a second copy of the object code. If that doesn't work then it
> would be helpful if you could produce a minimal reproducer of it not
> working. (The potential disadvantage is that you have to load the
> entirety of each of your dependencies, rather than just the parts you
> actually use.)
I do build dynamically, since it's the only option nowadays to load .o
files, but I guess what you mean is link the application as a shared
library, and then link it to the Main module for the app, and pass it
to GHC.parseDynamicFlags for the REPL? That's a good idea. But I'd
still be loading all those .hi files, and if the majority of the
memory use is actually from those, it might not help, right?
I don't fully understand the "have to load the entirety of your
dependencies" part. If I'm using the same code linked into the main
application, then isn't it a given that I'm loading everything in the
application in the first place? Or do you mean load all the .hi
files, even if I'm not exposing functions from them? If the size of
in-memory .hi files dwarfs the binary size, then that might be a net
lose. Though if my guess is correct about most .hi files being loaded
from external packages, then maybe there won't be much difference.
From allbery.b at gmail.com Tue Dec 13 18:30:15 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 13 Dec 2016 13:30:15 -0500
Subject: GHC API: memory usage of loaded modules
In-Reply-To:
References:
Message-ID:
On Tue, Dec 13, 2016 at 1:21 PM, Evan Laforge wrote:
> If I'm using the same code linked into the main
> application, then isn't it a given that I'm loading everything in the
> application in the first place?
>
It's not necessarily accessible in a useful form for use by demand loaded
modules; this is a common issue, leading to things like Apache and Perl
moving most of their implementation into shared objects specifically so
this kind of sharing will work. Additionally, since the demand loaded
environment is a separate evaluation environment, all data will necessarily
be duplicated (in theory sharing of initialized data with copy on write is
possible, but in practice it's a lot of work and demand loading overhead
for (for most C/C++ programs at least; ghc initialized data might differ)
very little practical gain).
--
brandon s allbery kf8nh sine nomine associates
allbery.b at gmail.com ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rwbarton at gmail.com Wed Dec 14 16:21:07 2016
From: rwbarton at gmail.com (Reid Barton)
Date: Wed, 14 Dec 2016 11:21:07 -0500
Subject: GHC API: memory usage of loaded modules
In-Reply-To:
References:
Message-ID:
On Tue, Dec 13, 2016 at 1:21 PM, Evan Laforge wrote:
> Sorry about the delay, I got distracted by an unrelated memory leak.
>
> On Tue, Nov 29, 2016 at 9:35 AM, Reid Barton wrote:
>> You'd probably find that you also want to, for example, type check the
>> expressions that you are interpreting. The information needed to do so
>> is not contained in your executable at all; it's in the .hi files that
>> were built alongside your program and its dependencies, and the ones
>> that came with the libraries bundled into GHC. I assume the in-memory
>> representation of these interface files is not very efficient, and
>> they probably account for a lot of the space usage of your program.
>
> That's true, but the .hi files on disk take up about 20k of that 76mb.
> If the .o files are loaded basically directly as binary, then that
> would mean 20k of .hi files turn into around 124mb in memory, which is
> quite an expansion. But then there's all of the libraries I use and
> then all their libraries... perhaps those need to be loaded too? If
> so, there is more than I'm counting. I'm not sure how to count those,
> since they're not included in the "upsweep" log msgs when you do a
> GHC.load.
GHCi definitely needs to load some .hi files of your dependencies.
Your .hi files contain the types of your functions, needed to type
check expressions that use them. Let's say the type of one of your
functions involves ByteString. Then GHCi has to read the interface
file that defines ByteString, so that there is something in the
compiler for the type of your function to refer to.
I'm not sure how to predict what exact set of .hi files GHCi will need
to load, but you could run your program under strace (or equivalent)
to see which .hi files it is loading. Then I would guess the expansion
factor when converting into the compiler's internal types is maybe
around 10x. However there's also some kind of lazy loading of .hi
files, and I'm not sure how that works or what granularity it has.
By the way, you can use `ghc --show-iface` to examine .hi files
manually, which might be illuminating.
>> If you build your executable dynamically then the GHC API should also
>> reuse the same shared libraries and executable image rather than
>> loading a second copy of the object code. If that doesn't work then it
>> would be helpful if you could produce a minimal reproducer of it not
>> working. (The potential disadvantage is that you have to load the
>> entirety of each of your dependencies, rather than just the parts you
>> actually use.)
>
> I do build dynamically, since it's the only option nowadays to load .o
> files, but I guess what you mean is link the application as a shared
> library, and then link it to the Main module for the app, and pass it
> to GHC.parseDynamicFlags for the REPL? That's a good idea. But I'd
> still be loading all those .hi files, and if the majority of the
> memory use is actually from those, it might not help, right?
I'm pretty sure the old way of linking your program statically, which
will cause the RTS to use its own linker to load .o files, is still
supposed to work. It has the same limitations it has always had, of
course. The new thing is that you need to build dynamically in order
to link object files into the ghc compiler itself; but that's just
because the ghc binary shipped in the binary distribution was built
dynamically; this isn't a constraint on your own GHC API use. (And you
can choose to build ghc statically, too. Windows builds still work
that way.)
I really just meant building your executable dynamically, i.e., with
-dynamic. If the code size is a small proportion of the total memory
use then it won't make a big difference, as you say. However, I'm not
sure that is really the case considering that the GHC library itself
is already about 74 MB on-disk.
I'm not sure why you are looking at the GHC.Stats.currentBytesUsed
number; be aware that it only measures the size of the GCed heap. Many
things that contribute to the total memory usage of your program (such
as its code size, or anything allocated by malloc or mmap) will not
show up there.
> I don't fully understand the "have to load the entirety of your
> dependencies" part. If I'm using the same code linked into the main
> application, then isn't it a given that I'm loading everything in the
> application in the first place?
Let me explain what I meant with an example. If I build a hello world
program statically, I get a 1.2M executable. Let's assume most of that
size comes from the base package. If I build the same hello world
program dynamically, I get an 18K executable dynamically linked
against an 11M base shared library! At runtime, the dynamic loader
will map that whole 11M file into my process's memory space. Whether
you want to count that as part of the space usage of your program is
up to you; the code segments will be shared between multiple
simultaneous instances of your program (or other programs compiled by
GHC), but if you only run one copy of your program at a time, that
doesn't help you. It certainly won't be counted by currentBytesUsed.
The base library is composed of many individual .o files. When I
linked the hello world statically, the linker took only the .o files
that were actually needed for my program, which is why it was only
1.2M when the base library is 11M. Your real program probably uses
most of base, but may have other dependencies that you use only a
small part of (lens?)
Now when you use the RTS linker in a statically linked program,
although some of the code you need is linked into your program
already, it's not in a usable form for the RTS linker, so it has to
load the .o files itself, effectively creating a second copy of the
code. If you used dynamic linking, then the RTS calls dlopen which
should reuse the mappings that were made when your program was loaded.
The tradeoff is that if you use very little of your dependencies then
it still might be cheaper to store two copies of only the code that
you actually do use.
Regards,
Reid Barton
From qdunkan at gmail.com Thu Dec 15 06:55:32 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed, 14 Dec 2016 22:55:32 -0800
Subject: GHC API: memory usage of loaded modules
In-Reply-To:
References:
Message-ID:
On Wed, Dec 14, 2016 at 8:21 AM, Reid Barton wrote:
> On Tue, Dec 13, 2016 at 1:21 PM, Evan Laforge wrote:
> GHCi definitely needs to load some .hi files of your dependencies.
> Your .hi files contain the types of your functions, needed to type
> check expressions that use them. Let's say the type of one of your
> functions involves ByteString. Then GHCi has to read the interface
> file that defines ByteString, so that there is something in the
> compiler for the type of your function to refer to.
Right, that makes sense. When I enable verbose logging, I see that in
the upsweep phase it collects the imports of all of the transitively
loaded modules. I assume it loads all the local .hi files, and then
it also has to load the package dependency .hi files (--show-iface
also shows a "package dependencies" section). I can't tell if it does
that lazily, but it would make sense because surely I'm not using
every single module exported from every single package. Certainly
packages themselves can be loaded lazily, I frequently see ghci wait
until I try to evaluate an expression to link in a bunch of external
packages.
> I'm not sure how to predict what exact set of .hi files GHCi will need
> to load, but you could run your program under strace (or equivalent)
> to see which .hi files it is loading. Then I would guess the expansion
> factor when converting into the compiler's internal types is maybe
> around 10x. However there's also some kind of lazy loading of .hi
> files, and I'm not sure how that works or what granularity it has.
I guess it would be dtrace on OS X, I'll look into it and see what I
can learn. Then I can divide the size of the loaded .hi files by the
increase in memory size and see what the ratio actually is.
> By the way, you can use `ghc --show-iface` to examine .hi files
> manually, which might be illuminating.
That is pretty interesting, thanks. There's quite a lot of stuff in
there, including some I didn't expect, like apparently lots of Show
instance implementations for concrete types:
bac9698d086d969aebee0847bf123997
$s$fShow(,)_$s$fShow(,)_$cshowList ::
[(Writable, SaveFile)] -> ShowS
In this case, both Writable and SaveFile are defined elsewhere, but I
do show a list of them in that module so maybe the instances get
inlined in here?
But it's not a crazy amount of stuff, and I wouldn't expect it, since
the .hi files themselves are not unreasonably large.
>> I do build dynamically, since it's the only option nowadays to load .o
>> files, but I guess what you mean is link the application as a shared
>> library, and then link it to the Main module for the app, and pass it
>> to GHC.parseDynamicFlags for the REPL? That's a good idea. But I'd
>> still be loading all those .hi files, and if the majority of the
>> memory use is actually from those, it might not help, right?
>
> I'm pretty sure the old way of linking your program statically, which
> will cause the RTS to use its own linker to load .o files, is still
> supposed to work. It has the same limitations it has always had, of
> course. The new thing is that you need to build dynamically in order
> to link object files into the ghc compiler itself; but that's just
> because the ghc binary shipped in the binary distribution was built
> dynamically; this isn't a constraint on your own GHC API use. (And you
> can choose to build ghc statically, too. Windows builds still work
> that way.)
I see from my darcs history that I added -dynamic to all builds except
profiling back in July 2014, I think after upgrading to 7.8. From the
comment, I did that because otherwise ghci wouldn't load the .o files.
And I remember lots of talk on trac around 7.8 about finally
abandoning the home-grown linker. This is on OS X, so maybe it's
platform dependent.
> I really just meant building your executable dynamically, i.e., with
> -dynamic. If the code size is a small proportion of the total memory
> use then it won't make a big difference, as you say. However, I'm not
> sure that is really the case considering that the GHC library itself
> is already about 74 MB on-disk.
In that case, I must already be doing that. But how would that work
for my own application's binary? When I do otool -L I see that indeed
all the cabal libraries like libHSbase and libHSghc are dynamic
libraries, so presumably those will be shared across the whole OS.
But application's binary is linked via 'ghc -dynamic -package=... A.o
B.o C.o etc'. The .o files are built with -dynamic and I assume ghci
itself uses the OS's loader for them, but they seem to be linked into
the binary in the traditional static way.
It's confusing to me because traditionally -dynamic is a link only
flag, but ghc also uses it for building .o files... I assume because
of the ghci loading thing. I always assumed it used the OS's low
level shared object loading, but not the whole dynamic library
mechanism.
> I'm not sure why you are looking at the GHC.Stats.currentBytesUsed
> number; be aware that it only measures the size of the GCed heap. Many
> things that contribute to the total memory usage of your program (such
> as its code size, or anything allocated by malloc or mmap) will not
> show up there.
I just picked it out of GCStats as having a promising looking name.
It's the one the goes up while the GHC API is loading its modules, so
I assumed it was the most useful one.
currentBytesUsed reports 200mb, but the system process viewer shows
350mb, so clearly some isn't being counted. But that looks like
2-space GC overhead, and indeed if I do +RTS -c, the system usage goes
down to 240mb while currentBytesUsed stays around 200mb (it goes up a
bit actually). So perhaps most of the allocation is indeed in the
GCed heap, and the extra space is mostly GC overhead. Does the GHC
API use malloc or mmap internally? I wouldn't be surprised if .o
files are loaded with mmap.
Another thing that occurred to me, if the GC heap is really mostly
loaded .hi files, then maybe I should increase the number of
generations since most of the heap is immortal. Or maybe when the
static regions stuff stabilizes, all the .hi data could go into a
static region. I guess that might require non-trivial ghc hacking
though.
>> I don't fully understand the "have to load the entirety of your
>> dependencies" part. If I'm using the same code linked into the main
>> application, then isn't it a given that I'm loading everything in the
>> application in the first place?
>
> Let me explain what I meant with an example. If I build a hello world
> program statically, I get a 1.2M executable. Let's assume most of that
> size comes from the base package. If I build the same hello world
> program dynamically, I get an 18K executable dynamically linked
> against an 11M base shared library! At runtime, the dynamic loader
> will map that whole 11M file into my process's memory space. Whether
> you want to count that as part of the space usage of your program is
> up to you; the code segments will be shared between multiple
> simultaneous instances of your program (or other programs compiled by
> GHC), but if you only run one copy of your program at a time, that
> doesn't help you. It certainly won't be counted by currentBytesUsed.
>
> The base library is composed of many individual .o files. When I
> linked the hello world statically, the linker took only the .o files
> that were actually needed for my program, which is why it was only
> 1.2M when the base library is 11M. Your real program probably uses
> most of base, but may have other dependencies that you use only a
> small part of (lens?)
Oh ok, that makes sense. In that case, because I'm dynamically
linking cabal packages, then certainly I'm already getting that
sharing. I was mostly concerned with the code from my program itself.
The REPL is only loading about 255 of the 401 local .o files, and
presumably if I link those 401 modules into a local dynlib, and then
link that to both the Main module and have the GHC API load it, then
I'd also share the local code. Since my program uses all of its own
code kind of by definition, it's loaded no matter what, even if the
REPL doesn't need all of it.
From allbery.b at gmail.com Thu Dec 15 15:45:58 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 15 Dec 2016 10:45:58 -0500
Subject: GHC API: memory usage of loaded modules
In-Reply-To:
References:
Message-ID:
On Thu, Dec 15, 2016 at 1:55 AM, Evan Laforge wrote:
> It's confusing to me because traditionally -dynamic is a link only
> flag, but ghc also uses it for building .o files... I assume because
> of the ghci loading thing.
>
There may also be some OS X specific behavior here; OS X doesn't like
static objects much, due to its PPC heritage (the PPC ABI pretty much
restricts "normal" position-dependent static objects to the kernel).
--
brandon s allbery kf8nh sine nomine associates
allbery.b at gmail.com ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ben at smart-cactus.org Thu Dec 15 18:13:26 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 15 Dec 2016 13:13:26 -0500
Subject: bus error in Integer calculations
In-Reply-To: <201612082343.uB8Nh8gK008815@linux1.cs.ox.ac.uk>
References: <201612082343.uB8Nh8gK008815@linux1.cs.ox.ac.uk>
Message-ID: <87d1gtjc1l.fsf@ben-laptop.smart-cactus.org>
Geraint Jones writes:
> 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.
>
For the record this was reported as GHC #12954.
Cheers,
- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL:
From conal at conal.net Sat Dec 17 05:42:54 2016
From: conal at conal.net (Conal Elliott)
Date: Fri, 16 Dec 2016 21:42:54 -0800
Subject: Inlining phase control for derived methods?
Message-ID:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ben.franksen at online.de Sat Dec 17 22:29:18 2016
From: ben.franksen at online.de (Ben Franksen)
Date: Sat, 17 Dec 2016 23:29:18 +0100
Subject: Allow extra commas in module declarations or lists?
In-Reply-To: <1465734244.2063.10.camel@joachim-breitner.de>
References:
<1465734244.2063.10.camel@joachim-breitner.de>
Message-ID:
Sorry for late comment.
Am 12.06.2016 um 14:24 schrieb Joachim Breitner:
> Am Samstag, den 11.06.2016, 12:12 -0700 schrieb Michael Burge:
> I propose allowing an optional single extra comma at the end in module
> declarations, record declarations, record constructors, and list
> constructors:
>
> module Example (
> module Example,
> SomeConstructor(..),
> ) where
>
> data SomeConstructor = SomeConstructor {
> foo :: Int,
> bar :: Int,
> }
>
> baz :: SomeConstructor -> SomeConstructor
> baz x = x {
> foo = 5,
> bar = 10,
> }
>
> qux :: [ Int ]
> qux = [
> 1,
> 2,
> 3,
> ]
>> What do you think?
>
> For the module header, this is already possible.
>
> For the term language, it unfortunately clashes with things like
> TupleSections.
Tuples haven't been mentioned by the OP. Indeed, extra commas don't make
any sense for tuples so let's just forget about them.
> I believe this has been discussed a few times in the past, e.g.
> https://mail.haskell.org/pipermail/haskell-prime/2013-May/003833.html
And, like here, people concentrate on the red herring 'tuple sections'.
To repeat (and slightly flesh out) the proposal:
Allow an optional single extra comma at the end in:
* module import and export lists
* record declarations
* record constructors
* record updates
* list constructors
I can't see anything problematic with that.
Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams
From anthony_clayden at clear.net.nz Sun Dec 18 05:38:59 2016
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Sun, 18 Dec 2016 18:38:59 +1300
Subject: [ghc-devs]: Explicit inequality evidence
Message-ID: <585620f3.42.3b2b.2472@clear.net.nz>
[transferring to -users, because there's a much wider
discussion]
> > On Dec 13, 2016, at 15:04, Richard Eisenberg wrote:
> > I've thought about inequality on and off for years now,
The subject has appeared (in various guises) on Haskell
forums since well before 2002 [1]
-- which went into the 'OutsideIn(X)' model.
Search the cafe on 'type disequality', for example.
> >> On Tue, Dec 13, 2016 at 12:49 AM, Oleg Grenrus wrote:
> >> First the bike shedding: Id prefer /~ and :/~:.
And yes, usually discussed with /~ as the type inequality
operator, since at least when ~ was introduced for type
equality.
> > ... but it's a hard nut to crack.
Which is presumably why spj has never shown any interest.
> > ... need evidence of inequality in Core, and
> > a brand-spanking-new type safety proof. ...
One rule of inference that David/Oleg haven't mentioned:
If x /~ y and y ~ z then x /~ z.
How does this go with (potentially) infinite type (family)s?
Thanks Richard for the refs on type safety proofs.
I wonder if anything in type safety relies on inequalities?
(This would be with, say, overlaps + fundeps extensions.)
FunDep 'confluence' (which Richard has re-christened
'coincident overlap' for closed type families),
surely relies on proving at some use site
that the types can never unify with such-and-such instance
(or type family equation).
For example if we have
instance C a a where ...
instance C a b where...
We have to prove at a use site that the two types
cannot unify, to justify picking the second instance.
This goes badly with separate compilation:
suppose the `C a a` instance is not visible in every module.
I would love type inequality guards on instances
to be explored as an alternative approach for overlap.
(See some of my reponses to Richard [2].)
In my example above:
instance C a b | a /~ b where ...
So the invisibility of the `C a a` instance would not upset
any use sites.
[1] Sulzmann and Stuckey 2002 'A theory of Overloading'
[2]
https://typesandkinds.wordpress.com/2013/04/29/coincident-overlap-in-type-families/
AntC
From david.feuer at gmail.com Wed Dec 21 19:04:55 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 21 Dec 2016 14:04:55 -0500
Subject: Retro-Haskell: can we get seq somewhat under control?
Message-ID:
In the Old Days (some time before Haskell 98), `seq` wasn't fully
polymorphic. It could only be applied to instances of a certain class.
I don't know the name that class had, but let's say Seq. Apparently,
some people didn't like that, and now it's gone. I'd love to be able
to turn on a language extension, use an alternate Prelude, and get it
back. I'm not ready to put up a full-scale proposal yet; I'm hoping
some people may have suggestions for details. Some thoughts:
1. Why do you want that crazy thing, David?
When implementing general-purpose lazy data structures, a *lot* of
things need to be done strictly for efficiency. Often, the easiest way
to do this is using either bang patterns or strict data constructors.
Care is necessary to only ever force pieces of the data structure, and
not the polymorphic data a user has stored in it.
2. Why does it need GHC support?
It would certainly be possible to write alternative versions of `seq`,
`$!`, and `evaluate` to use a user-supplied Seq class. It should even
be possible to deal with strict data constructors by hand or
(probably) using Template Haskell. For instance,
data Foo a = Foo !Int !a
would translate to normal GHC Haskell as
data Foo a = Seq a => Foo !Int !a
But only GHC can extend this to bang patterns, deal with the
interactions with coercions, and optimize it thoroughly.
3. How does Seq interact with coercions and roles?
I believe we'd probably want a special rule that
(Seq a, Coercible a b) => Seq b
Thanks to this rule, a Seq constraint on a type variable shouldn't
prevent it from having a representational role.
The downside of this rule is that if something *can* be forced, but we
don't *want* it to be, then we have to hide it a little more carefully
than we might like. This shouldn't be too hard, however, using a
newtype defined in a separate module that exports a pattern synonym
instead of a constructor, to hide the coercibility.
4. Optimize? What?
Nobody wants Seq constraints blocking up specialization. Today, a function
foo :: (Seq a, Foldable f) => f a -> ()
won't specialize to the Foldable instance if the Seq instance is
unknown. This is lousy. Furthermore, all Seq instances are the same.
The RTS doesn't actually need a dictionary to force something to WHNF.
The situation is somewhat similar to that of Coercible, *but more so*.
Coercible sometimes needs to pass evidence at runtime to maintain type
safety. But Seq carries no type safety hazard whatsoever--when
compiling in "production mode", we can just *assume* that Seq evidence
is valid, and erase it immediately after type checking; the worst
thing that could possibly happen is that someone will force a function
and get weird semantics. Further, we should *unconditionally* erase
Seq evidence from datatypes; this is necessary to maintain
compatibility with the usual data representations. I don't know if
this unconditional erasure could cause "laziness safety" issues, but
the system would be essentially unusable without it.
4. What would the language extension do, exactly?
a. Automatically satisfy Seq for data types and families.
b. Propagate Seq constraints using the usual rules and the special
Coercible rule.
c. Modify the translation of strict fields to add Seq constraints as required.
David Feuer
From anthony_clayden at clear.net.nz Thu Dec 22 01:45:08 2016
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Thu, 22 Dec 2016 14:45:08 +1300
Subject: [ghc-devs]: Explicit inequality evidence
Message-ID: <585b3024.1a0.3c7e.18262@clear.net.nz>
> On Dec 13, 2016, at 1:02 AM, David Feuer wrote:
>
>> On Tue, Dec 13, 2016 at 12:49 AM, Oleg Grenrus
wrote:
>>
>> I assume that in your rules, variables are not type
families, otherwise
>>
>> x /~ y => f x /~ f y doesn't hold if `f` isn't injective.
(e.g. type family F x where F x = ())
>> other direction is true though.
>
> I was definitely imagining them as first-class types; your
point that
> f x /~ f y => x /~ y even if f is a type family is an
excellent one.
>
Hmm, yes except: how would evidence ever arise that f x /~ f
y ?
Would we ever get a 'wanted' constraint to that effect?
More likely, we'd be trying to discriminate between
instances
in which picking some instance depends on f x /~ f y.
I don't see that any of the overlap/closed type family work
has got us away from the 'groundedness issues'
observed in the HList paper.
We have to improve both types to a grounded type constructor
to get the evidence they're not equal.
(Or at least that parameters in the same position are not
equal,
and that the type constructors are not familys and are the
same arity.)
AntC
From ekmett at gmail.com Thu Dec 22 04:55:43 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 21 Dec 2016 23:55:43 -0500
Subject: Retro-Haskell: can we get seq somewhat under control?
In-Reply-To:
References:
Message-ID:
Actually, if you go back to the original form of Seq it would translate to
data Seq a => Foo a = Foo !Int !a
which requires resurrecting DatatypeContexts, and not
data Foo a = Seq a => Foo !Int !a
The former requires Seq to call the constructor, but doesn't pack the
dictionary into the constructor. The latter lets you get the dictionary out
when you pattern match on it. meaning it has to carry the dictionary around!
Unfortunately, non-trivial functionality is lost. With the old
DatatypeContext translation you can't always unpack and repack a
constructor. Whereas with a change to an existential encoding you're
carrying around a lot of dictionaries in precisely the structures that
least want to carry extra weight.
Both of these options suck relative to the status quo for different reasons.
-Edward
On Wed, Dec 21, 2016 at 2:14 PM, Index Int wrote:
> There's a related GHC Proposal:
> https://github.com/ghc-proposals/ghc-proposals/pull/27
>
> On Wed, Dec 21, 2016 at 10:04 PM, David Feuer
> wrote:
> > In the Old Days (some time before Haskell 98), `seq` wasn't fully
> > polymorphic. It could only be applied to instances of a certain class.
> > I don't know the name that class had, but let's say Seq. Apparently,
> > some people didn't like that, and now it's gone. I'd love to be able
> > to turn on a language extension, use an alternate Prelude, and get it
> > back. I'm not ready to put up a full-scale proposal yet; I'm hoping
> > some people may have suggestions for details. Some thoughts:
> >
> > 1. Why do you want that crazy thing, David?
> >
> > When implementing general-purpose lazy data structures, a *lot* of
> > things need to be done strictly for efficiency. Often, the easiest way
> > to do this is using either bang patterns or strict data constructors.
> > Care is necessary to only ever force pieces of the data structure, and
> > not the polymorphic data a user has stored in it.
> >
> > 2. Why does it need GHC support?
> >
> > It would certainly be possible to write alternative versions of `seq`,
> > `$!`, and `evaluate` to use a user-supplied Seq class. It should even
> > be possible to deal with strict data constructors by hand or
> > (probably) using Template Haskell. For instance,
> >
> > data Foo a = Foo !Int !a
> >
> > would translate to normal GHC Haskell as
> >
> > data Foo a = Seq a => Foo !Int !a
> >
> > But only GHC can extend this to bang patterns, deal with the
> > interactions with coercions, and optimize it thoroughly.
> >
> > 3. How does Seq interact with coercions and roles?
> >
> > I believe we'd probably want a special rule that
> >
> > (Seq a, Coercible a b) => Seq b
> >
> > Thanks to this rule, a Seq constraint on a type variable shouldn't
> > prevent it from having a representational role.
> >
> > The downside of this rule is that if something *can* be forced, but we
> > don't *want* it to be, then we have to hide it a little more carefully
> > than we might like. This shouldn't be too hard, however, using a
> > newtype defined in a separate module that exports a pattern synonym
> > instead of a constructor, to hide the coercibility.
> >
> > 4. Optimize? What?
> >
> > Nobody wants Seq constraints blocking up specialization. Today, a
> function
> >
> > foo :: (Seq a, Foldable f) => f a -> ()
> >
> > won't specialize to the Foldable instance if the Seq instance is
> > unknown. This is lousy. Furthermore, all Seq instances are the same.
> > The RTS doesn't actually need a dictionary to force something to WHNF.
> > The situation is somewhat similar to that of Coercible, *but more so*.
> > Coercible sometimes needs to pass evidence at runtime to maintain type
> > safety. But Seq carries no type safety hazard whatsoever--when
> > compiling in "production mode", we can just *assume* that Seq evidence
> > is valid, and erase it immediately after type checking; the worst
> > thing that could possibly happen is that someone will force a function
> > and get weird semantics. Further, we should *unconditionally* erase
> > Seq evidence from datatypes; this is necessary to maintain
> > compatibility with the usual data representations. I don't know if
> > this unconditional erasure could cause "laziness safety" issues, but
> > the system would be essentially unusable without it.
> >
> > 4. What would the language extension do, exactly?
> >
> > a. Automatically satisfy Seq for data types and families.
> > b. Propagate Seq constraints using the usual rules and the special
> > Coercible rule.
> > c. Modify the translation of strict fields to add Seq constraints as
> required.
> >
> > David Feuer
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu Dec 22 05:13:37 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 22 Dec 2016 00:13:37 -0500
Subject: Retro-Haskell: can we get seq somewhat under control?
In-Reply-To:
References:
Message-ID:
I don't want to actually put the dictionary there. I want to *pretend* to
put the dictionary there. In testing mode, I want to be able to "take one
out" by making it out of whole cloth; in production mode I want to just
assume there are no bottoms in the constraints and never ever make the
dictionaries. But this all is probably better discussed on the existing
proposal, now that I know it exists. There are some considerable
complications raised there.
On Dec 21, 2016 11:55 PM, "Edward Kmett" wrote:
> Actually, if you go back to the original form of Seq it would translate to
>
> data Seq a => Foo a = Foo !Int !a
>
> which requires resurrecting DatatypeContexts, and not
>
> data Foo a = Seq a => Foo !Int !a
>
> The former requires Seq to call the constructor, but doesn't pack the
> dictionary into the constructor. The latter lets you get the dictionary out
> when you pattern match on it. meaning it has to carry the dictionary around!
>
> Unfortunately, non-trivial functionality is lost. With the old
> DatatypeContext translation you can't always unpack and repack a
> constructor. Whereas with a change to an existential encoding you're
> carrying around a lot of dictionaries in precisely the structures that
> least want to carry extra weight.
>
> Both of these options suck relative to the status quo for different
> reasons.
>
> -Edward
>
> On Wed, Dec 21, 2016 at 2:14 PM, Index Int wrote:
>
>> There's a related GHC Proposal:
>> https://github.com/ghc-proposals/ghc-proposals/pull/27
>>
>> On Wed, Dec 21, 2016 at 10:04 PM, David Feuer
>> wrote:
>> > In the Old Days (some time before Haskell 98), `seq` wasn't fully
>> > polymorphic. It could only be applied to instances of a certain class.
>> > I don't know the name that class had, but let's say Seq. Apparently,
>> > some people didn't like that, and now it's gone. I'd love to be able
>> > to turn on a language extension, use an alternate Prelude, and get it
>> > back. I'm not ready to put up a full-scale proposal yet; I'm hoping
>> > some people may have suggestions for details. Some thoughts:
>> >
>> > 1. Why do you want that crazy thing, David?
>> >
>> > When implementing general-purpose lazy data structures, a *lot* of
>> > things need to be done strictly for efficiency. Often, the easiest way
>> > to do this is using either bang patterns or strict data constructors.
>> > Care is necessary to only ever force pieces of the data structure, and
>> > not the polymorphic data a user has stored in it.
>> >
>> > 2. Why does it need GHC support?
>> >
>> > It would certainly be possible to write alternative versions of `seq`,
>> > `$!`, and `evaluate` to use a user-supplied Seq class. It should even
>> > be possible to deal with strict data constructors by hand or
>> > (probably) using Template Haskell. For instance,
>> >
>> > data Foo a = Foo !Int !a
>> >
>> > would translate to normal GHC Haskell as
>> >
>> > data Foo a = Seq a => Foo !Int !a
>> >
>> > But only GHC can extend this to bang patterns, deal with the
>> > interactions with coercions, and optimize it thoroughly.
>> >
>> > 3. How does Seq interact with coercions and roles?
>> >
>> > I believe we'd probably want a special rule that
>> >
>> > (Seq a, Coercible a b) => Seq b
>> >
>> > Thanks to this rule, a Seq constraint on a type variable shouldn't
>> > prevent it from having a representational role.
>> >
>> > The downside of this rule is that if something *can* be forced, but we
>> > don't *want* it to be, then we have to hide it a little more carefully
>> > than we might like. This shouldn't be too hard, however, using a
>> > newtype defined in a separate module that exports a pattern synonym
>> > instead of a constructor, to hide the coercibility.
>> >
>> > 4. Optimize? What?
>> >
>> > Nobody wants Seq constraints blocking up specialization. Today, a
>> function
>> >
>> > foo :: (Seq a, Foldable f) => f a -> ()
>> >
>> > won't specialize to the Foldable instance if the Seq instance is
>> > unknown. This is lousy. Furthermore, all Seq instances are the same.
>> > The RTS doesn't actually need a dictionary to force something to WHNF.
>> > The situation is somewhat similar to that of Coercible, *but more so*.
>> > Coercible sometimes needs to pass evidence at runtime to maintain type
>> > safety. But Seq carries no type safety hazard whatsoever--when
>> > compiling in "production mode", we can just *assume* that Seq evidence
>> > is valid, and erase it immediately after type checking; the worst
>> > thing that could possibly happen is that someone will force a function
>> > and get weird semantics. Further, we should *unconditionally* erase
>> > Seq evidence from datatypes; this is necessary to maintain
>> > compatibility with the usual data representations. I don't know if
>> > this unconditional erasure could cause "laziness safety" issues, but
>> > the system would be essentially unusable without it.
>> >
>> > 4. What would the language extension do, exactly?
>> >
>> > a. Automatically satisfy Seq for data types and families.
>> > b. Propagate Seq constraints using the usual rules and the special
>> > Coercible rule.
>> > c. Modify the translation of strict fields to add Seq constraints as
>> required.
>> >
>> > David Feuer
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ben at well-typed.com Thu Dec 22 19:38:58 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 22 Dec 2016 14:38:58 -0500
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 2
Message-ID: <87vaub7nzh.fsf@ben-laptop.smart-cactus.org>
Hello everyone,
The GHC team is happy to announce the second 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-rc2/
This is the second and likely final release candidate leading up the
8.0.2 release. This release will fix a number of 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.
This release candidate fixes a number of issues present in -rc1,
* #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.
If all goes well we should have a final 8.0.2 release out shortly after
the new year. 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&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL:
From george.colpitts at gmail.com Thu Dec 22 23:23:58 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 22 Dec 2016 23:23:58 +0000
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 2
In-Reply-To: <87vaub7nzh.fsf@ben-laptop.smart-cactus.org>
References: <87vaub7nzh.fsf@ben-laptop.smart-cactus.org>
Message-ID:
compiled from source with no issues on Mac OS 10.12.2 with XCode 8.2.1.
Compiled vector package with it, did some smoke testing of the runtime,
seems fine
On Thu, Dec 22, 2016 at 3:39 PM Ben Gamari wrote:
>
> Hello everyone,
>
> The GHC team is happy to announce the second 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-rc2/
>
> This is the second and likely final release candidate leading up the
> 8.0.2 release. This release will fix a number of 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.
>
> This release candidate fixes a number of issues present in -rc1,
>
> * #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.
>
> If all goes well we should have a final 8.0.2 release out shortly after
> the new year. 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&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From george.colpitts at gmail.com Fri Dec 23 00:05:49 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Fri, 23 Dec 2016 00:05:49 +0000
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 2
In-Reply-To:
References: <87vaub7nzh.fsf@ben-laptop.smart-cactus.org>
Message-ID:
binary works fine also, same env, same testing as with compiled source
I did notice a very minor infelicity in the TOC for the pdf User's Guide. I
think it was there in rc1 also
The formatting seems to assume there are are never more than 3 digits on
lines such as the following and is missing a space when there are 4 digits,
e.g.
10.7 Pattern synonyms . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 267
10.8 Class and instances declarations . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . 273
10.9 Type families . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 294
10.10Datatype promotion . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 308
10.11Kind polymorphism and Type-in-Type . . . . . . . . . . . . . . . . .
. . . . . . . . . 311
10.12Runtime representation polymorphism . .
On Thu, Dec 22, 2016 at 7:23 PM George Colpitts
wrote:
> compiled from source with no issues on Mac OS 10.12.2 with XCode 8.2.1.
> Compiled vector package with it, did some smoke testing of the runtime,
> seems fine
>
> On Thu, Dec 22, 2016 at 3:39 PM Ben Gamari wrote:
>
>
> Hello everyone,
>
> The GHC team is happy to announce the second 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-rc2/
>
> This is the second and likely final release candidate leading up the
> 8.0.2 release. This release will fix a number of 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.
>
> This release candidate fixes a number of issues present in -rc1,
>
> * #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.
>
> If all goes well we should have a final 8.0.2 release out shortly after
> the new year. 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&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mblazevic at stilo.com Fri Dec 23 17:21:32 2016
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 23 Dec 2016 12:21:32 -0500
Subject: Retro-Haskell: can we get seq somewhat under control?
In-Reply-To:
References:
Message-ID: <13729990-2127-83e2-9d4e-b2478d694c26@stilo.com>
On 2016-12-21 02:04 PM, David Feuer wrote:
> In the Old Days (some time before Haskell 98), `seq` wasn't fully
> polymorphic. It could only be applied to instances of a certain class.
> I don't know the name that class had, but let's say Seq. Apparently,
> some people didn't like that, and now it's gone. I'd love to be able
> to turn on a language extension, use an alternate Prelude, and get it
> back. I'm not ready to put up a full-scale proposal yet; I'm hoping
> some people may have suggestions for details.
I've already put up a proposal here:
https://github.com/ghc-proposals/ghc-proposals/pull/27
There are serious problems with the proposal as it stands, though. I'm
hoping to patch some holes in it over the holidays. In the meantime,
feel free to add your comments.
From juhpetersen at gmail.com Wed Dec 28 01:46:39 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Wed, 28 Dec 2016 10:46:39 +0900
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 2
In-Reply-To: <87vaub7nzh.fsf@ben-laptop.smart-cactus.org>
References: <87vaub7nzh.fsf@ben-laptop.smart-cactus.org>
Message-ID:
On 23 December 2016 at 04:38, Ben Gamari wrote:
> The GHC team is happy to announce the second candidate of the
> 8.0.2 release of the Glasgow Haskell Compiler.
>
Thanks
Fedora users can install it from my Fedora Copr Repo:
https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.2/
There will be an EPEL7 build too for the final release.
Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From conal at conal.net Thu Dec 29 00:27:20 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 28 Dec 2016 16:27:20 -0800
Subject: GHC rewrite rules for class operations & laws
In-Reply-To:
References:
Message-ID:
Hi, George. Yes, please do add a task, hopefully to serve as a conversation
anchor until the issues and path forward are clearer. From my perspective,
class methods are among the most natural and useful candidates for rewrite
rules, since they tend to have associated laws, many (but not all) of which
are helpful in optimization. The alternative I know (and am using) is
fairly inconvenient: replicating entire APIs just in order to delay
inlining long enough to apply rules.
Thanks, - Conal
On Sun, Dec 11, 2016 at 7:24 AM, George Colpitts
wrote:
> Do you want me to add a task ticket to remove this restriction that
> rewrite rules can't be used for class methods?
>
> On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via
> Glasgow-haskell-users wrote:
>
>> Conal
>>
>>
>>
>> Is it possible to apply GHC rewrite rules to class methods?
>>
>>
>>
>> Not currently. See https://ghc.haskell.org/trac/ghc/ticket/11688, esp
>> comment:7 which gives links to similar examples.
>> https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more
>> background.
>>
>>
>>
>> It’d be great if someone wanted to think through all this.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Glasgow-haskell-users [mailto:glasgow-haskell-users-
>> bounces at haskell.org] *On Behalf Of *Conal Elliott
>> *Sent:* 17 November 2016 16:40
>> *To:* glasgow-haskell-users at haskell.org
>> *Subject:* GHC rewrite rules for class operations & laws
>>
>>
>>
>> Is it possible to apply GHC rewrite rules to class methods? From what
>> I’ve read and seen, class methods get eliminated early by
>> automatically-generated rules. Is there really no way to postpone such
>> inlining until a later simplifier stage? The GHC Users Guide docs say no
>> ,
>> and suggests instead giving a duplicate vocabulary with somewhat awkward
>> names for class methods. I’ve not seen this practice in libraries. I gather
>> that we cannot therefore use class laws as optimizations in the form of
>> rewrite rules, which seems a terrible loss.
>>
>> In Control.Category and Control.Arrow, I see rules for class laws but
>> also header comments saying “The RULES for the methods of class Arrow may
>> never fire e.g. compose/arr; see Trac #10528”.
>>
>> I’d appreciate a reality check about my conclusions as well as any
>> strategies for using class laws in optimization.
>>
>> Thanks, -- Conal
>> _______________________________________________
>> 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 ben at smart-cactus.org Thu Dec 29 14:50:00 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 29 Dec 2016 09:50:00 -0500
Subject: GHC rewrite rules for class operations & laws
In-Reply-To:
References:
Message-ID: <8E34955B-4717-4DD7-AB1C-36DF072B4195@smart-cactus.org>
On December 28, 2016 7:27:20 PM EST, Conal Elliott wrote:
>Hi, George. Yes, please do add a task, hopefully to serve as a
>conversation
>anchor until the issues and path forward are clearer. From my
>perspective,
>class methods are among the most natural and useful candidates for
>rewrite
>rules, since they tend to have associated laws, many (but not all) of
>which
>are helpful in optimization. The alternative I know (and am using) is
>fairly inconvenient: replicating entire APIs just in order to delay
>inlining long enough to apply rules.
>
Indeed, we could eliminate several hundred lines of boilerplate in GHC if we could lift this restriction.
Cheers,
- Ben
From george.colpitts at gmail.com Fri Dec 30 13:11:34 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Fri, 30 Dec 2016 13:11:34 +0000
Subject: GHC rewrite rules for class operations & laws
In-Reply-To:
References:
Message-ID:
Done: https://ghc.haskell.org/trac/ghc/ticket/13044#ticket
Not sure if it fully captures what you want so people should feel free to
edit.
Cheers
George
On Wed, Dec 28, 2016 at 8:27 PM Conal Elliott wrote:
> Hi, George. Yes, please do add a task, hopefully to serve as a
> conversation anchor until the issues and path forward are clearer. From my
> perspective, class methods are among the most natural and useful candidates
> for rewrite rules, since they tend to have associated laws, many (but not
> all) of which are helpful in optimization. The alternative I know (and am
> using) is fairly inconvenient: replicating entire APIs just in order to
> delay inlining long enough to apply rules.
>
> Thanks, - Conal
>
>
> On Sun, Dec 11, 2016 at 7:24 AM, George Colpitts <
> george.colpitts at gmail.com> wrote:
>
> Do you want me to add a task ticket to remove this restriction that
> rewrite rules can't be used for class methods?
>
> On Tue, Nov 22, 2016 at 8:06 AM Simon Peyton Jones via
> Glasgow-haskell-users wrote:
>
> Conal
>
>
>
> Is it possible to apply GHC rewrite rules to class methods?
>
>
>
> Not currently. See https://ghc.haskell.org/trac/ghc/ticket/11688, esp
> comment:7 which gives links to similar examples.
> https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more
> background.
>
>
>
> It’d be great if someone wanted to think through all this.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 17 November 2016 16:40
> *To:* glasgow-haskell-users at haskell.org
> *Subject:* GHC rewrite rules for class operations & laws
>
>
>
> Is it possible to apply GHC rewrite rules to class methods? From what I’ve
> read and seen, class methods get eliminated early by
> automatically-generated rules. Is there really no way to postpone such
> inlining until a later simplifier stage? The GHC Users Guide docs say no
> ,
> and suggests instead giving a duplicate vocabulary with somewhat awkward
> names for class methods. I’ve not seen this practice in libraries. I gather
> that we cannot therefore use class laws as optimizations in the form of
> rewrite rules, which seems a terrible loss.
>
> In Control.Category and Control.Arrow, I see rules for class laws but
> also header comments saying “The RULES for the methods of class Arrow may
> never fire e.g. compose/arr; see Trac #10528”.
>
> I’d appreciate a reality check about my conclusions as well as any
> strategies for using class laws in optimization.
>
> Thanks, -- Conal
> _______________________________________________
> 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: