PUBLIC
PUBLIC
Thanks for looking into this!
`Paths_ghc_lib` is referenced just because I am using GHC via ghc-lib. You can of course instead use a local full build of GHC for the libDir. Please find an updated version
attached that does that – you’ll just have to adapt the definition of `libDir` to your environment.
As for opening a ticket – a big part of the problem is that I don’t even know yet if I’m doing something wrong, or GHC is! So it’s not clear what the ticket would even be for
– “I’m using the GHC API wrongly” is not a strong bug report 😊
From: Simon Peyton Jones <simonpj@microsoft.com>
Sent: Saturday, October 16, 2021 12:52 AM
To: Erdi, Gergo <Gergo.Erdi@sc.com>; 'Matthew Pickering' <matthewtpickering@gmail.com>
Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com>; 'GHC' <ghc-devs@haskell.org>
Subject: [External] RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
I could not compile Main.hs:
~/code/HEAD-1/inplace/bin/ghc-stage1 -c Gergo.hs -package ghc
Gergo.hs:4:1: error:
Could not find module ‘Paths_ghc_lib’
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
4 | import qualified Paths_ghc_lib as GHC
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
simonpj@MSRC-3645512:~/tmp$
Would you like to open a ticket rather than do this by email?
Simon
PS: I am leaving Microsoft at the end of November 2021, at which point
simonpj@microsoft.com will cease to work. Use
simon.peytonjones@gmail.com instead. (For now, it just forwards to
simonpj@microsoft.com.)
From: Erdi, Gergo <Gergo.Erdi@sc.com>
Sent: 15 October 2021 05:35
To: Simon Peyton Jones <simonpj@microsoft.com>; 'Matthew Pickering' <matthewtpickering@gmail.com>
Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com>; 'GHC' <ghc-devs@haskell.org>
Subject: RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
PUBLIC
PUBLIC
OK I now have a standalone demonstrator that shows, at least, that the default method implementation is not specialized. With the attached input programs, the resulting Core
(using GHC e46edfcf47d674731935b2ea1443cc7927e071fb) is as follows (only showing the relevant parts):
seq :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b
seq
= \ (@(m :: * -> *)) (v_srS [Occ=Once1!] :: Monad m) ->
case v_srS of { C:Monad _ [Occ=Dead] v_srV [Occ=Once1] -> v_srV }
$dmseq :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b
$dmseq
= \ (@(m :: * -> *))
($dMonad [Occ=Once1] :: Monad m)
(@a)
(@b)
(ma [Occ=Once1] :: m a)
(mb [Occ=OnceL1] :: m b) ->
let {
sat_ss0 [Occ=Once1] :: a -> m b
[LclId]
sat_ss0 = \ _ [Occ=Dead] -> mb } in
bind @m $dMonad @a @b ma sat_ss0
$fMonadIO :: Monad IO
$fMonadIO = C:Monad @IO bindIO $fMonadIO_$cseq;
$fMonadIO_$cseq :: forall a b. IO a -> IO b -> IO b
$fMonadIO_$cseq = \ (@a) (@b) -> $dmseq @IO $fMonadIO @a @b;
foo :: IO ()
foo = seq @IO $fMonadIO @() @() ioA ioA
If I turn on Opt_D_dump_spec, I can see that specializer *is* running, it just doesn’t *do* anything.