- ghc-devs - Haskell.org

Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings
by Erdi, Gergo 06 Apr '22

06 Apr '22

PUBLIC Please see this question in my previous email: * Unfortunately, I am unable to reproduce this from the command line using the GHC executable, so before I put in the effort of making a minimal example of using the GHC API to get this result, I would first like to know if this is even an interesting case, or if there is some explanation for why one of these two would have an unfolding when the other doesn't, in certain cases. So I can NOT reproduce it with just a GHC command line, only with my program (that uses GHC as a library). So it will require extra effort to get something you or others can just run, hence my question: is there anything here that is worth pursuing at all? Or who cares, since I'm not using unfoldings anymore (I've switched over to storing IfaceExprs directly), and it works in GHC-the-program? From: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Sent: Wednesday, April 6, 2022 3:37 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: Gergo Érdi <gergo(a)erdi.hu>; GHC Devs <ghc-devs(a)haskell.org>; clash-language(a)googlegroups.com Subject: [External] Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings Hi Gergo If you think GHC has a but, can you open a ticket about this? It's all getting lost in a maze of emails. Can you also give precise repro instructions? In an attempt to reproduce, I have just compiled this module (the code you gave) {-# OPTIONS_GHC -fexpose-all-unfoldings #-} module Foo where nonEmptySubsequences :: [a] -> [[a]] nonEmptySubsequences [] = [] nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs) where f ys r = ys : (x:ys) : r subsequences :: [a] -> [[a]] subsequences xs = [] : nonEmptySubsequences xs with HEAD, and -O. Unlike you, I see both unfoldings in the interface file. So clearly you and I are doing different things -- but I can't work out what is different without more precision about what you are doing. (It would be harder if it only happens when you use GHC as a library, but I think you are seeing this behaviour in regular GHC.) Thanks Simon On Wed, 6 Apr 2022 at 03:05, Erdi, Gergo <Gergo.Erdi(a)sc.com<mailto:Gergo.Erdi@sc.com>> wrote: PUBLIC Just so this isn't prematurely all lost, I went back and looked for this example. With the following two definitions: subsequences :: [a] -> [[a]] subsequences xs = [] : nonEmptySubsequences xs nonEmptySubsequences :: [a] -> [[a]] nonEmptySubsequences [] = [] nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs) where f ys r = ys : (x : ys) : r If I save the interface, load it back and look at the unfoldings, I see that `subsequences` has a useful unfolding: subsequences Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 10} Whereas `nonEmptySubsequenes` has a trivial one: nonEmptySubsequences OtherCon [] The interface I save is created from the ModDetails returned by tidyProgram. ExposeAllUnfoldings is set. Unfortunately, I am unable to reproduce this from the command line using the GHC executable, so before I put in the effort of making a minimal example of using the GHC API to get this result, I would first like to know if this is even an interesting case, or if there is some explanation for why one of these two would have an unfolding when the other doesn't, in certain cases. -----Original Message----- From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of Gergo Érdi Sent: Saturday, April 2, 2022 11:31 AM To: Simon Peyton Jones <simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com>> Cc: GHC Devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>>; clash-language(a)googlegroups.com<mailto:clash-language@googlegroups.com> Subject: [External] Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings I'm using Prep's output (mostly so that it's in ANF) in my full compilation pipeline, so ideally I would save Prep'd Core in my .hi-equivalents so that I don't have to rerun Prep on them every time I use them. I'll get back to you with some concrete examples of `OtherCon []` vs. meaningful unfoldings next week. Merging with my other question about shadowing problems with `toIface*`, in summary it seems that what I really should be doing, is compiling up to Tidy, taking the `CoreBinding`s from there and using `toIfaceBinding` on them to save the definitions. 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<http://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/<http://www.sc.com/rcs/> and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm<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<http://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<https://clicktime.symantec.com/3GBVJVK63nbzRga3gfUDE6Z7VN?u=http%3A%2F%2Fre…>. 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/<http://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.

2 1

Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings
by Erdi, Gergo 06 Apr '22

06 Apr '22

PUBLIC Just so this isn't prematurely all lost, I went back and looked for this example. With the following two definitions: subsequences :: [a] -> [[a]] subsequences xs = [] : nonEmptySubsequences xs nonEmptySubsequences :: [a] -> [[a]] nonEmptySubsequences [] = [] nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs) where f ys r = ys : (x : ys) : r If I save the interface, load it back and look at the unfoldings, I see that `subsequences` has a useful unfolding: subsequences Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 10} Whereas `nonEmptySubsequenes` has a trivial one: nonEmptySubsequences OtherCon [] The interface I save is created from the ModDetails returned by tidyProgram. ExposeAllUnfoldings is set. Unfortunately, I am unable to reproduce this from the command line using the GHC executable, so before I put in the effort of making a minimal example of using the GHC API to get this result, I would first like to know if this is even an interesting case, or if there is some explanation for why one of these two would have an unfolding when the other doesn't, in certain cases. -----Original Message----- From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Gergo Érdi Sent: Saturday, April 2, 2022 11:31 AM To: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Cc: GHC Devs <ghc-devs(a)haskell.org>; clash-language(a)googlegroups.com Subject: [External] Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings I'm using Prep's output (mostly so that it's in ANF) in my full compilation pipeline, so ideally I would save Prep'd Core in my .hi-equivalents so that I don't have to rerun Prep on them every time I use them. I'll get back to you with some concrete examples of `OtherCon []` vs. meaningful unfoldings next week. Merging with my other question about shadowing problems with `toIface*`, in summary it seems that what I really should be doing, is compiling up to Tidy, taking the `CoreBinding`s from there and using `toIfaceBinding` on them to save the definitions. 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.

2 1

Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings
by ÉRDI Gergő 06 Apr '22

06 Apr '22

Hi, I'm CC-ing the Clash mailing list because I believe they should have encountered the same problem (and perhaps have found a solution to it already!). I'm trying to use `.hi` files compiled with `ExposeAllUnfoldings` set to reconstruct full Core bindings for further processing. By and large, this works, but I get tripped up on identifiers whose unfolding is only given as `OtherCon []`. It is unclear to me what is causing this -- some of them are recursive bindings while others are not. The problem, of course, is that if all I know about an identifier is that it is `OtherCon []`, that doesn't allow me to restore its definition. So is there a way to tell GHC to put "full" unfoldings everywhere in `ExposeAllUnfoldings` mode? Thanks, Gergo

8 10

Could margebot squash?
by Joachim Breitner 04 Apr '22

04 Apr '22

Hi, as far as I understand, the expected workflow for MRs is that when they are ready, the developer manually squashes the chronological commit history of the MR into a logical one with polished commit messages, typically consisting of a single commit, but could be multiple ones, and then assigns the MR to margebot, which will rebase that sequence of commits onto the staging branch and eventually merges that into master. One downside of this approach is that it requires destructive changes to work-in-progres branches: I might think the MR is ready, squash the commit sequence into a single commit, but then more work is ready. Now it’s hard to revert individual patches, or collaborate with others, because the git history was disrupted. Another is that the commit message itself isn’t very easily visible to reviewers. In other similarly sized projects (e.g. mathlib) I often see a mode where the actual commits of the MR are ignored (so they can represent the true git history of the branch, including merges and all that grit, which is good for collaboration and for reviewers to understand what has happened, without requiring developers to spend cosmetics effort on them), and upon merging by margebot/bors/mergify/whatever, the MR is merged as a single commit with the description taken from the MR description (which encourages developers to keep the MR description up to date as the MR develops, reviewers can easily see that). A downside of this that you’ll always get one commit on master per MR. If you like to submit a curated list of logical commits within one MR, then this would not work, and you’d have to use multiple MRs. Has this been considered? (I don’t want to cause unnecessary disruption with a presumptious call for action here; take it as a comment to weigh in in if and when this part of our infrastructure is about to change anyways, or maybe a careful probe if my sentiment may be shared widely.) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 5

Shadowing in toIface* output
by ÉRDI Gergő 04 Apr '22

04 Apr '22

Hi, I'm trying to save (Prep'd) Core bindings right next to the serialized `ModIface` (so basically `put_`ing them into the same bytestream, after the `ModIface`), and that's exactly what the functions in `GHC.CoreToIface` seem to be for, so I expected it to Just Work. However, I noticed that I very frequently get problems with shadowing. For example, Core that looks like `\v{u1} v{u2} -> v{u1}` would get translated to `\v v -> v`, which is disastrous since these locally bound `Var`s are represented as just their `getOccFS` (i.e. the `FastString` `"v"`). But this can't be right: if `toIfaceExpr` &c. would fail this blatently, then the unfoldings couldn't be saved & restored, which is something GHC itself does as part of normal `.hi` file handling. So clearly I must be doing something wrong. So I guess my question could be, what could be causing `toIfaceExpr` (a pure function!) to behave this way for my Cores? But then, if I look at the implementation of `toIface*`, I can see that it really doesn't do anything smarter than just storing `getOccFS` in the interface (no uniques in sight)-- so maybe my *real* question is, what is GHC itself doing so that it doesn't have this same problem? Thanks, Gergo

5 5

Windows CI instability
by Matthew Pickering 01 Apr '22

01 Apr '22

Hi all, Currently the windows CI issue is experiencing high amounts of instability so if your patch fails for this reason then don't worry. We are attempting to fix it. Cheers, Matt

1 0

devel2 build flavour thoughts
by Matthew Pickering 01 Apr '22

01 Apr '22

Hi all, In semi-private I have been making very bold claims about the unsuitability of the devel2 as a build flavour of choice for the aspiring developer. In order to bolster my claim I set out to find out some statistics about 1. devel2 flavour 2. default+no_profiled_libs+omit_pragmas+assertions flavour The difference between the two is essentially that flavour (2) builds each module with optimisation but disables cross-module optimisation (in particular inlining) In short the difference between the two flavours is negligible from my testing apart from one larger difference when building larger packages. Full build + test: Near identical Testsuite run: Near identical Recompile: Near identical - (2) is slower Build Cabal: 167s vs 259s So if you want to build packages use flavour 2 but otherwise it seems to make little difference. Cheers, Matt

2 1

question about mapSuccessors in GHC.Cmm.Node
by Norman Ramsey 30 Mar '22

30 Mar '22

Does anyone know why the continuations of CmmCall and CmmForeignCall are not considered successors for the purpose of `mapSuccessors`? Norman

1 0

safe maps within GHC?
by Norman Ramsey 29 Mar '22

29 Mar '22

A blog post of lexi-lambda's recently put me onto Matt Noonan's technique "Ghosts of Departed Proofs" [1], which appeared in the 2018 Haskell Symposium. One example that intrigued me was a safe `Map`, which uses the type system to guarantee that lookup does not fail. Maps are used pretty extensively in Cmm-land; for example, I recently have been using them to get information like the dominator set or the reverse postorder number of every node in a `CmmGraph`. In these maps, every `Label` that appears in the `CmmGraph` is expected to have an entry. For the moment, I am just using the standard lookup function; if an entry should be missing, my code calls `panic`. The idea of eliminating these calls and getting compile-time type safety is intriguing, but I'm not sure the game is worth the candle. What do other GHC devs think? Norman [1] https://iohk.io/en/research/library/papers/ghosts-of-departed-proofsfunctio…

3 3

Call for Talks: Haskell Implementors' Workshop 2022
by Alejandro Serrano Mena 23 Mar '22

23 Mar '22

(apologies for multiple copies of this message) ACM SIGPLAN Haskell Implementors' Workshop https://icfp22.sigplan.org/home/hiw-2022 Ljubljana, Slovenia, 11 September 2022 Co-located with ICFP 2022 https://icfp22.sigplan.org/ Important dates --------------- Deadline: 11 July, 2022 (AoE) Notification: 11 August, 2022 Workshop: 11 September, 2022 The 14th Haskell Implementors' Workshop is to be held alongside ICFP 2022 this year in Ljubljana. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2022. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfphiw22.hotcrp.com until July 11th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Pepe Iborra (Meta) * Gabrielle Keller (Utrecht University) * Emily Pilmore (Kadena) * Vladislav Zavialov (Serokell) * Alejandro Serrano (Tweag) Contact ------- * Alejandro Serrano <trupill at gmail.com>

1 0