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. From: Erdi, Gergo Sent: Monday, October 11, 2021 4:00 PM 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 (RE: Instantiation of overloaded definition *in Core*) PUBLIC Trust me when I say I understand your frustration. It is even more frustrating for me not to be able to just send a Github repo link containing my code... I'll try to make an MWE that demonstrates the problem but it will probably take quite some time. I was hoping that maybe there's some known gotcha that I'm not aware of - for example (see my other thread), I just discovered that setting optimization flags one by one isn't equal to setting them wholesale with -On, so I was *not* running specialisation in my normal (per-module) pipeline at all! Unfortunately, now that I've discovered this and made sure optLevel is set to at least 1, I am still seeing the polymorphic default implementation of >> as the only one :/ I also tried to be cheeky about the binding order and put the whole collected CoreProgram into a single Rec binder to test your guess, since that should make the actual textual order irrelevant. Unfortunately, that sill doesn't change anything :/ From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Monday, October 11, 2021 3:33 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients. It's incredibly hard to debug this sort of thing remotely, without the ability to reproduce it. First, you are using a variant of GHC, with changes that we can only guess at. Second, even with unmodified GHC I often find that unexpected things happen - until I dig deeper and it becomes obvious! There is one odd thing about your dump: it seems to be in reverse dependency order, with functions being defined before they are used, rather than after. That would certainly stop the specialiser from working. The occurrence analyser would sort this out (literally). But that's a total guess. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 11 October 2021 03:58 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC PUBLIC Hi Simon, Matt & others, It took me until now to be able to try out GHC HEAD, mostly because I had to adapt to all the GHC.Unit.* refactorings. However, now I am on a466b02492f73a43c6cb9ce69491fc85234b9559 which includes the commit Simon pointed out. My original plan was to expose the first half of specProgram, i.e. the part that calls `go binds`. I did that because I want to apply specialisation on collected whole-program Core, not just whatever would be in scope for a Core-to-Core plugin pass, so I am not writing a CoreM and I don't even have a ModGuts at hand. However, I found out from Matt's email on this thread that this is not going to be enough and eventually I'll need to figure out how I intend to apply the rewrite rules that come out of this. So for now, I am just turning on specialization in the normal pipeline by setting Opt_Specialise, Opt_SpecialiseAggressively, and Opt_CrossModuleSpecialise. And I'm still not seeing $dm>> being specialized. Is this because I define each of "class Monad", "data IO a", "instance Monad IO", and "main", in four distinct modules? In other words, is this something I will not be able to try out until I figure out how to make a fake ModGuts and run a CoreM from outside the normal compilation pipeline, feeding it the whole-program collected CoreBinds? But if so, why is it that when I feed my whole program to just specBinds (which I can try easily since it has no ModGuts/CoreM dependency other than a uniq supply and the CoreProgram), I get back an empty UsageDetails? Thanks, Gergo For reference, the relevant definitions dumped from GHC with specialization (supposedly) turned on: main = $fMonadIO_$c>> @() @() sat_sJg xmain $fMonadIO_$c>> :: forall a b. IO a -> IO b -> IO b $fMonadIO_$c>> = \ (@a_aF9) (@b_aFa) -> $dm>> @IO $fMonadIO @a_aF9 @b_aFa; $dm>> :: forall (m :: Type -> Type) a b. Monad m => m a -> m b -> m b $dm>> = \ (@(m_ani :: Type -> Type)) ($dMonad_sIi [Occ=Once1] :: Monad m_ani) (@a_ar4) (@b_ar5) (ma_sIj [Occ=Once1] :: m_ani a_ar4) (mb_sIk [Occ=OnceL1] :: m_ani b_ar5) -> let { sat_sIm [Occ=Once1] :: a_ar4 -> m_ani b_ar5 [LclId] sat_sIm = \ _ [Occ=Dead] -> mb_sIk } in >>= @m_ani $dMonad_sIi @a_ar4 @b_ar5 ma_sIj sat_sIm From: Erdi, Gergo Sent: Thursday, October 7, 2021 9:30 AM To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; GHC <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC Indeed, I am using 9.0.1. I'll try upgrading. Thanks! From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Wednesday, October 6, 2021 6:12 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; GHC <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) Grego, Yes I think that should auto-specialise. Which version of GHC are you using? Do you have this patch? commit ef0135934fe32da5b5bb730dbce74262e23e72e8 Author: Simon Peyton Jones simonpj@microsoft.com<mailto:simonpj@microsoft.com> Date: Thu Apr 8 22:42:31 2021 +0100 Make the specialiser handle polymorphic specialisation Here's why I ask. The call $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b indeed applies $dm>> to $fMonadIO, but it also applies it to a and b. In the version of GHC you have, maybe that stops the call from floating up to the definition site, and being used to specialise it. Can you make a repro case without your plugin? Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
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<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto: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. From: Erdi, Gergo Sent: Monday, October 11, 2021 4:00 PM To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC Trust me when I say I understand your frustration. It is even more frustrating for me not to be able to just send a Github repo link containing my code... I'll try to make an MWE that demonstrates the problem but it will probably take quite some time. I was hoping that maybe there's some known gotcha that I'm not aware of - for example (see my other thread), I just discovered that setting optimization flags one by one isn't equal to setting them wholesale with -On, so I was *not* running specialisation in my normal (per-module) pipeline at all! Unfortunately, now that I've discovered this and made sure optLevel is set to at least 1, I am still seeing the polymorphic default implementation of >> as the only one :/ I also tried to be cheeky about the binding order and put the whole collected CoreProgram into a single Rec binder to test your guess, since that should make the actual textual order irrelevant. Unfortunately, that sill doesn't change anything :/ From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Monday, October 11, 2021 3:33 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients. It's incredibly hard to debug this sort of thing remotely, without the ability to reproduce it. First, you are using a variant of GHC, with changes that we can only guess at. Second, even with unmodified GHC I often find that unexpected things happen - until I dig deeper and it becomes obvious! There is one odd thing about your dump: it seems to be in reverse dependency order, with functions being defined before they are used, rather than after. That would certainly stop the specialiser from working. The occurrence analyser would sort this out (literally). But that's a total guess. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 11 October 2021 03:58 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC PUBLIC Hi Simon, Matt & others, It took me until now to be able to try out GHC HEAD, mostly because I had to adapt to all the GHC.Unit.* refactorings. However, now I am on a466b02492f73a43c6cb9ce69491fc85234b9559 which includes the commit Simon pointed out. My original plan was to expose the first half of specProgram, i.e. the part that calls `go binds`. I did that because I want to apply specialisation on collected whole-program Core, not just whatever would be in scope for a Core-to-Core plugin pass, so I am not writing a CoreM and I don't even have a ModGuts at hand. However, I found out from Matt's email on this thread that this is not going to be enough and eventually I'll need to figure out how I intend to apply the rewrite rules that come out of this. So for now, I am just turning on specialization in the normal pipeline by setting Opt_Specialise, Opt_SpecialiseAggressively, and Opt_CrossModuleSpecialise. And I'm still not seeing $dm>> being specialized. Is this because I define each of "class Monad", "data IO a", "instance Monad IO", and "main", in four distinct modules? In other words, is this something I will not be able to try out until I figure out how to make a fake ModGuts and run a CoreM from outside the normal compilation pipeline, feeding it the whole-program collected CoreBinds? But if so, why is it that when I feed my whole program to just specBinds (which I can try easily since it has no ModGuts/CoreM dependency other than a uniq supply and the CoreProgram), I get back an empty UsageDetails? Thanks, Gergo For reference, the relevant definitions dumped from GHC with specialization (supposedly) turned on: main = $fMonadIO_$c>> @() @() sat_sJg xmain $fMonadIO_$c>> :: forall a b. IO a -> IO b -> IO b $fMonadIO_$c>> = \ (@a_aF9) (@b_aFa) -> $dm>> @IO $fMonadIO @a_aF9 @b_aFa; $dm>> :: forall (m :: Type -> Type) a b. Monad m => m a -> m b -> m b $dm>> = \ (@(m_ani :: Type -> Type)) ($dMonad_sIi [Occ=Once1] :: Monad m_ani) (@a_ar4) (@b_ar5) (ma_sIj [Occ=Once1] :: m_ani a_ar4) (mb_sIk [Occ=OnceL1] :: m_ani b_ar5) -> let { sat_sIm [Occ=Once1] :: a_ar4 -> m_ani b_ar5 [LclId] sat_sIm = \ _ [Occ=Dead] -> mb_sIk } in >>= @m_ani $dMonad_sIi @a_ar4 @b_ar5 ma_sIj sat_sIm From: Erdi, Gergo Sent: Thursday, October 7, 2021 9:30 AM To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; GHC <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) PUBLIC Indeed, I am using 9.0.1. I'll try upgrading. Thanks! From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Wednesday, October 6, 2021 6:12 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; GHC <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) Grego, Yes I think that should auto-specialise. Which version of GHC are you using? Do you have this patch? commit ef0135934fe32da5b5bb730dbce74262e23e72e8 Author: Simon Peyton Jones simonpj@microsoft.com<mailto:simonpj@microsoft.com> Date: Thu Apr 8 22:42:31 2021 +0100 Make the specialiser handle polymorphic specialisation Here's why I ask. The call $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b indeed applies $dm>> to $fMonadIO, but it also applies it to a and b. In the version of GHC you have, maybe that stops the call from floating up to the definition site, and being used to specialise it. Can you make a repro case without your plugin? Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
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<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 15 October 2021 05:35 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
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 😊 Plenty of tickets turn out to be non-bugs. But they are still searchable, and form a permanent record that may help others, perhaps in unexpected ways. So I encourage you to do so. I successfully compiled the attached Main.hs with HEAD, passing ‘-package ghc’ as a command line argument. When I run it I get simonpj@MSRC-3645512:~/tmp$ ./gergo Missing file: /home/simonpj/code/HEAD-1/compiler/stage1/build/settings So now I’m stuck again. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com.) From: Erdi, Gergo <Gergo.Erdi@sc.com> Sent: 19 October 2021 02:57 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 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<mailto:simonpj@microsoft.com>> Sent: Saturday, October 16, 2021 12:52 AM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 15 October 2021 05:35 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
PUBLIC PUBLIC Do you have a full GHC build there? Are you using Hadrian? Did you set `libDir`’s definition in the source file to where you have GHC built? I just tried, and if I remove the files from my GHC build, I am able to rebuild them: mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do rm ~/prog/ghc/_build/stage1/lib/$i; done mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do ./hadrian/build-stack _build/stage1/lib/$i; done | Successfully generated _build/stage1/lib/settings. Build completed in 0.41s | Copy file: llvm-passes => _build/stage1/lib/llvm-passes Build completed in 0.40s | Copy file: llvm-targets => _build/stage1/lib/llvm-targets Build completed in 0.52s From: Simon Peyton Jones <simonpj@microsoft.com> Sent: Tuesday, October 19, 2021 3:54 PM 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*) 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 😊 Plenty of tickets turn out to be non-bugs. But they are still searchable, and form a permanent record that may help others, perhaps in unexpected ways. So I encourage you to do so. I successfully compiled the attached Main.hs with HEAD, passing ‘-package ghc’ as a command line argument. When I run it I get simonpj@MSRC-3645512:~/tmp$ ./gergo Missing file: /home/simonpj/code/HEAD-1/compiler/stage1/build/settings So now I’m stuck again. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 19 October 2021 02:57 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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 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<mailto:simonpj@microsoft.com>> Sent: Saturday, October 16, 2021 12:52 AM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 15 October 2021 05:35 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
Yes I have a full build. No it was not built with Hadrian. I did not realise that your system relied not only on GHC as a library, but also on the build system that you use to build GHC. I guess I can try that, but probably not today. But what is “settings”? Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com.) From: Erdi, Gergo <Gergo.Erdi@sc.com> Sent: 19 October 2021 09:03 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 Do you have a full GHC build there? Are you using Hadrian? Did you set `libDir`’s definition in the source file to where you have GHC built? I just tried, and if I remove the files from my GHC build, I am able to rebuild them: mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do rm ~/prog/ghc/_build/stage1/lib/$i; done mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do ./hadrian/build-stack _build/stage1/lib/$i; done | Successfully generated _build/stage1/lib/settings. Build completed in 0.41s | Copy file: llvm-passes => _build/stage1/lib/llvm-passes Build completed in 0.40s | Copy file: llvm-targets => _build/stage1/lib/llvm-targets Build completed in 0.52s From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Tuesday, October 19, 2021 3:54 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*) 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 😊 Plenty of tickets turn out to be non-bugs. But they are still searchable, and form a permanent record that may help others, perhaps in unexpected ways. So I encourage you to do so. I successfully compiled the attached Main.hs with HEAD, passing ‘-package ghc’ as a command line argument. When I run it I get simonpj@MSRC-3645512:~/tmp$ ./gergo Missing file: /home/simonpj/code/HEAD-1/compiler/stage1/build/settings So now I’m stuck again. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 19 October 2021 02:57 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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 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<mailto:simonpj@microsoft.com>> Sent: Saturday, October 16, 2021 12:52 AM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 15 October 2021 05:35 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
PUBLIC PUBLIC “settings”? Honestly, I have no idea. GHC looks at these files in the directory passed to runGhc, and in my local setup I have some convoluted ghc-lib-based system to persist these files and also the base package.db into a Stack/cabal-installable package, but these are only needed for environments where there’s no bona-fide GHC build directory. I am sure even without Hadrian, you should have these files somewhere under your build directory, since otherwise the same same runGhc function (used inside the GHC executable as well…) wouldn’t work. Maybe someone else with non-Hadrian knowledge can tell you where these files are put in the non-Hadrian build. From: Simon Peyton Jones <simonpj@microsoft.com> Sent: Tuesday, October 19, 2021 4:08 PM 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*) Yes I have a full build. No it was not built with Hadrian. I did not realise that your system relied not only on GHC as a library, but also on the build system that you use to build GHC. I guess I can try that, but probably not today. But what is “settings”? Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 19 October 2021 09:03 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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 Do you have a full GHC build there? Are you using Hadrian? Did you set `libDir`’s definition in the source file to where you have GHC built? I just tried, and if I remove the files from my GHC build, I am able to rebuild them: mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do rm ~/prog/ghc/_build/stage1/lib/$i; done mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do ./hadrian/build-stack _build/stage1/lib/$i; done | Successfully generated _build/stage1/lib/settings. Build completed in 0.41s | Copy file: llvm-passes => _build/stage1/lib/llvm-passes Build completed in 0.40s | Copy file: llvm-targets => _build/stage1/lib/llvm-targets Build completed in 0.52s From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Tuesday, October 19, 2021 3:54 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*) 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 😊 Plenty of tickets turn out to be non-bugs. But they are still searchable, and form a permanent record that may help others, perhaps in unexpected ways. So I encourage you to do so. I successfully compiled the attached Main.hs with HEAD, passing ‘-package ghc’ as a command line argument. When I run it I get simonpj@MSRC-3645512:~/tmp$ ./gergo Missing file: /home/simonpj/code/HEAD-1/compiler/stage1/build/settings So now I’m stuck again. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 19 October 2021 02:57 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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 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<mailto:simonpj@microsoft.com>> Sent: Saturday, October 16, 2021 12:52 AM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 15 October 2021 05:35 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
I’m out of cycles. Do please open a ticket. You are more likely to get attention that way. Matthew: maybe you can help with reproducing this? SImon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com.) From: Erdi, Gergo <Gergo.Erdi@sc.com> Sent: 19 October 2021 09:36 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 “settings”? Honestly, I have no idea. GHC looks at these files in the directory passed to runGhc, and in my local setup I have some convoluted ghc-lib-based system to persist these files and also the base package.db into a Stack/cabal-installable package, but these are only needed for environments where there’s no bona-fide GHC build directory. I am sure even without Hadrian, you should have these files somewhere under your build directory, since otherwise the same same runGhc function (used inside the GHC executable as well…) wouldn’t work. Maybe someone else with non-Hadrian knowledge can tell you where these files are put in the non-Hadrian build. From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Tuesday, October 19, 2021 4:08 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*) Yes I have a full build. No it was not built with Hadrian. I did not realise that your system relied not only on GHC as a library, but also on the build system that you use to build GHC. I guess I can try that, but probably not today. But what is “settings”? Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 19 October 2021 09:03 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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 Do you have a full GHC build there? Are you using Hadrian? Did you set `libDir`’s definition in the source file to where you have GHC built? I just tried, and if I remove the files from my GHC build, I am able to rebuild them: mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do rm ~/prog/ghc/_build/stage1/lib/$i; done mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do ./hadrian/build-stack _build/stage1/lib/$i; done | Successfully generated _build/stage1/lib/settings. Build completed in 0.41s | Copy file: llvm-passes => _build/stage1/lib/llvm-passes Build completed in 0.40s | Copy file: llvm-targets => _build/stage1/lib/llvm-targets Build completed in 0.52s From: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> Sent: Tuesday, October 19, 2021 3:54 PM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Subject: [External] RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*) 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 😊 Plenty of tickets turn out to be non-bugs. But they are still searchable, and form a permanent record that may help others, perhaps in unexpected ways. So I encourage you to do so. I successfully compiled the attached Main.hs with HEAD, passing ‘-package ghc’ as a command line argument. When I run it I get simonpj@MSRC-3645512:~/tmp$ ./gergo Missing file: /home/simonpj/code/HEAD-1/compiler/stage1/build/settings So now I’m stuck again. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 19 October 2021 02:57 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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 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<mailto:simonpj@microsoft.com>> Sent: Saturday, October 16, 2021 12:52 AM To: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones@gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj@microsoft.com<mailto:simonpj@microsoft.com>.) From: Erdi, Gergo <Gergo.Erdi@sc.com<mailto:Gergo.Erdi@sc.com>> Sent: 15 October 2021 05:35 To: Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>>; 'Matthew Pickering' <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici@sc.com<mailto:Raphael.Montelatici@sc.com>>; 'GHC' <ghc-devs@haskell.org<mailto: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. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
Hi, If there is a ticket then I can look into it next week. Cheers, Matt On Fri, Oct 22, 2021 at 12:11 PM Simon Peyton Jones <simonpj@microsoft.com> wrote:
I’m out of cycles. Do please open a ticket. You are more likely to get attention that way.
Matthew: maybe you can help with reproducing this?
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: 19 October 2021 09:36 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
“settings”? Honestly, I have no idea. GHC looks at these files in the directory passed to runGhc, and in my local setup I have some convoluted ghc-lib-based system to persist these files and also the base package.db into a Stack/cabal-installable package, but these are only needed for environments where there’s no bona-fide GHC build directory.
I am sure even without Hadrian, you should have these files somewhere under your build directory, since otherwise the same same runGhc function (used inside the GHC executable as well…) wouldn’t work. Maybe someone else with non-Hadrian knowledge can tell you where these files are put in the non-Hadrian build.
From: Simon Peyton Jones <simonpj@microsoft.com> Sent: Tuesday, October 19, 2021 4:08 PM 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*)
Yes I have a full build. No it was not built with Hadrian. I did not realise that your system relied not only on GHC as a library, but also on the build system that you use to build GHC.
I guess I can try that, but probably not today. But what is “settings”?
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: 19 October 2021 09:03 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
Do you have a full GHC build there? Are you using Hadrian? Did you set `libDir`’s definition in the source file to where you have GHC built? I just tried, and if I remove the files from my GHC build, I am able to rebuild them:
mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do rm ~/prog/ghc/_build/stage1/lib/$i; done
mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do ./hadrian/build-stack _build/stage1/lib/$i; done
| Successfully generated _build/stage1/lib/settings.
Build completed in 0.41s
| Copy file: llvm-passes => _build/stage1/lib/llvm-passes
Build completed in 0.40s
| Copy file: llvm-targets => _build/stage1/lib/llvm-targets
Build completed in 0.52s
From: Simon Peyton Jones <simonpj@microsoft.com> Sent: Tuesday, October 19, 2021 3:54 PM 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*)
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 😊
Plenty of tickets turn out to be non-bugs. But they are still searchable, and form a permanent record that may help others, perhaps in unexpected ways. So I encourage you to do so.
I successfully compiled the attached Main.hs with HEAD, passing ‘-package ghc’ as a command line argument.
When I run it I get
simonpj@MSRC-3645512:~/tmp$ ./gergo
Missing file: /home/simonpj/code/HEAD-1/compiler/stage1/build/settings
So now I’m stuck again.
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: 19 October 2021 02:57 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
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.
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations
Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations
Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations
Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions.
Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.
Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
On Fri, 22 Oct 2021, Matthew Pickering wrote:
If there is a ticket then I can look into it next week.
Thanks! I've added it as https://gitlab.haskell.org/ghc/ghc/-/issues/20556
participants (4)
-
Erdi, Gergo -
Matthew Pickering -
Simon Peyton Jones -
ÉRDI Gergő