- ghc-devs - Haskell.org

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

28 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

Wiki page for WebAssembly support in GHC
by Cheng Shao 03 Mar '22

03 Mar '22

Hi all, We're planning to add WebAssembly support to GHC. This work will be delivered by me and Norman Ramsey, the former Asterius team at Tweag. In the past few months, we did a strategic shift and focused on growing GHC towards Asterius, leveraging existing RTS as much as possible. We've made decent progress since then, and we expect to target 9.6 release much like GHCJS. We've created the https://gitlab.haskell.org/ghc/ghc/-/wikis/WebAssembly-backend wiki page, as a central point for communication. You're welcome to take a look and ask questions (either in this thread or editing that page in place), we'll answer the questions in the FAQ section. Cheers, Cheng

2 1

9.4 release planning (& GHCJS merge process)
by Matthew Pickering 24 Feb '22

24 Feb '22

Hi all, Firstly we are anticipating branching 9.4 in about 6 weeks time (approx start of April). Most of the major features originally milestoned[1] for this release have landed and the main branch is currently in a nice state. This timeline will be solidified once the 9.2.2 release has been completed. The major outstanding work that I am aware of is Windows toolchain work (#21019) (Ben Gamari) Partial Register Stall (#20405) (Andreas Klebinger) hi-haddock (!6224) (Zubin Duggal / Matthew Pickering ) Directed Coercions (!6476) (Sam Derbyshire) Secondly, we are anticipating adding a javascript backend inspired by GHCJS as the highlight of the 9.6 release. This work is led by the team at IOHK. * The planning and progress of this process is tracked on this wiki page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend * We anticipate reviewing and merging patches incrementally into a feature branch until the point where test coverage is suitable and the patches can be merged into the main branch. Cheers, Matt [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370

3 6

Well-Typed GHC team update
by Matthew Pickering 23 Feb '22

23 Feb '22

Hi all, We have recently reorganised the structure of the Well-Typed team working on the GHC project. In short, I am now responsible for more of the management tasks that Ben has traditionally carried out. In particular I have responsibility for organising the work between us and keeping track of the tasks that need to be completed. With that in mind, if you need something doing, please email/ping me and not Ben with your request and I will make sure someone deals with it. On gitlab you can also notify me directly by using the @hq-shepard tag, which provides the level of indirection for when this changes again in the future. The team working at Well-Typed on GHC currently consists of Myself (Matthew Pickering) Ben Gamari Andreas Klebinger Sam Derbyshire Zubin Duggal Cheers, Matt

3 2

struggling to get master to build
by Norman Ramsey 18 Feb '22

18 Feb '22

I recently pulled to bring my local copy of GHC HEAD up to 67dd5724297094af93be1887ef000845722c6f2b. But I cannot seem to get it to build. I'm following these steps: git pull --ff-only --prune --recurse-submodules --force rm -r _build ./boot ./configure ./hadrian build -j The build is failing with this error message: Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o >>> referenced by _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o:(.text+0x50) collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) Command failed Build failed. The offending command is very long indeed; it is appended to this message. What am I doing wrong, and what do I need to change? Norman Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf thr_dyn_hi -osuf thr_dyn_o -hcsuf thr_dyn_hc -fPIC -dynamic -optc-DTHREADED_RTS -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/nr/asterius/ghc/_build/stage1/rts/build -i/home/nr/asterius/ghc/_build/stage1/rts/build/autogen -i/home/nr/asterius/ghc/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -optP-include -optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -dynamic -shared -dynload deploy -optl-Wl,-rpath,$ORIGIN -optl-Wl,-zorigin -fno-use-rpaths -no-auto-link-packages -rtsopts -lc -lm -lrt -ldl -lpthread -lnuma -L_build/stage1/rts/build -lffi -Wnoncanonical-monad-instances -optc-Wno-error=inline -optP-Wno-nonportable-include-path _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o _build/stage1/rts/build/c/Adjustor.thr_dyn_o _build/stage1/rts/build/c/adjustor/AdjustorPool.thr_dyn_o _build/stage1/rts/build/c/ExecPage.thr_dyn_o _build/stage1/rts/build/c/Arena.thr_dyn_o _build/stage1/rts/build/c/Capability.thr_dyn_o _build/stage1/rts/build/c/CheckUnload.thr_dyn_o _build/stage1/rts/build/c/CloneStack.thr_dyn_o _build/stage1/rts/build/c/ClosureFlags.thr_dyn_o _build/stage1/rts/build/c/ClosureSize.thr_dyn_o _build/stage1/rts/build/c/Disassembler.thr_dyn_o _build/stage1/rts/build/c/FileLock.thr_dyn_o _build/stage1/rts/build/c/ForeignExports.thr_dyn_o _build/stage1/rts/build/c/Globals.thr_dyn_o _build/stage1/rts/build/c/Hash.thr_dyn_o _build/stage1/rts/build/c/Heap.thr_dyn_o _build/stage1/rts/build/c/Hpc.thr_dyn_o _build/stage1/rts/build/c/HsFFI.thr_dyn_o _build/stage1/rts/build/c/Inlines.thr_dyn_o _build/stage1/rts/build/c/Interpreter.thr_dyn_o _build/stage1/rts/build/c/IOManager.thr_dyn_o _build/stage1/rts/build/c/LdvProfile.thr_dyn_o _build/stage1/rts/build/c/Libdw.thr_dyn_o _build/stage1/rts/build/c/LibdwPool.thr_dyn_o _build/stage1/rts/build/c/Linker.thr_dyn_o _build/stage1/rts/build/c/ReportMemoryMap.thr_dyn_o _build/stage1/rts/build/c/Messages.thr_dyn_o _build/stage1/rts/build/c/OldARMAtomic.thr_dyn_o _build/stage1/rts/build/c/PathUtils.thr_dyn_o _build/stage1/rts/build/c/Pool.thr_dyn_o _build/stage1/rts/build/c/Printer.thr_dyn_o _build/stage1/rts/build/c/ProfHeap.thr_dyn_o _build/stage1/rts/build/c/ProfilerReport.thr_dyn_o _build/stage1/rts/build/c/ProfilerReportJson.thr_dyn_o _build/stage1/rts/build/c/Profiling.thr_dyn_o _build/stage1/rts/build/c/IPE.thr_dyn_o _build/stage1/rts/build/c/Proftimer.thr_dyn_o _build/stage1/rts/build/c/RaiseAsync.thr_dyn_o _build/stage1/rts/build/c/RetainerProfile.thr_dyn_o _build/stage1/rts/build/c/RetainerSet.thr_dyn_o _build/stage1/rts/build/c/RtsAPI.thr_dyn_o _build/stage1/rts/build/c/RtsDllMain.thr_dyn_o _build/stage1/rts/build/c/RtsFlags.thr_dyn_o _build/stage1/rts/build/c/RtsMain.thr_dyn_o _build/stage1/rts/build/c/RtsMessages.thr_dyn_o _build/stage1/rts/build/c/RtsStartup.thr_dyn_o _build/stage1/rts/build/c/RtsSymbolInfo.thr_dyn_o _build/stage1/rts/build/c/RtsSymbols.thr_dyn_o _build/stage1/rts/build/c/RtsUtils.thr_dyn_o _build/stage1/rts/build/c/STM.thr_dyn_o _build/stage1/rts/build/c/Schedule.thr_dyn_o _build/stage1/rts/build/c/Sparks.thr_dyn_o _build/stage1/rts/build/c/SpinLock.thr_dyn_o _build/stage1/rts/build/c/StableName.thr_dyn_o _build/stage1/rts/build/c/StablePtr.thr_dyn_o _build/stage1/rts/build/c/StaticPtrTable.thr_dyn_o _build/stage1/rts/build/c/Stats.thr_dyn_o _build/stage1/rts/build/c/StgCRun.thr_dyn_o _build/stage1/rts/build/c/StgPrimFloat.thr_dyn_o _build/stage1/rts/build/c/Task.thr_dyn_o _build/stage1/rts/build/c/ThreadLabels.thr_dyn_o _build/stage1/rts/build/c/ThreadPaused.thr_dyn_o _build/stage1/rts/build/c/Threads.thr_dyn_o _build/stage1/rts/build/c/Ticky.thr_dyn_o _build/stage1/rts/build/c/Timer.thr_dyn_o _build/stage1/rts/build/c/TopHandler.thr_dyn_o _build/stage1/rts/build/c/Trace.thr_dyn_o _build/stage1/rts/build/c/TraverseHeap.thr_dyn_o _build/stage1/rts/build/c/TraverseHeapTest.thr_dyn_o _build/stage1/rts/build/c/WSDeque.thr_dyn_o _build/stage1/rts/build/c/Weak.thr_dyn_o _build/stage1/rts/build/c/eventlog/EventLog.thr_dyn_o _build/stage1/rts/build/c/eventlog/EventLogWriter.thr_dyn_o _build/stage1/rts/build/c/hooks/FlagDefaults.thr_dyn_o _build/stage1/rts/build/c/hooks/LongGCSync.thr_dyn_o _build/stage1/rts/build/c/hooks/MallocFail.thr_dyn_o _build/stage1/rts/build/c/hooks/OnExit.thr_dyn_o _build/stage1/rts/build/c/hooks/OutOfHeap.thr_dyn_o _build/stage1/rts/build/c/hooks/StackOverflow.thr_dyn_o _build/stage1/rts/build/c/linker/CacheFlush.thr_dyn_o _build/stage1/rts/build/c/linker/Elf.thr_dyn_o _build/stage1/rts/build/c/linker/LoadArchive.thr_dyn_o _build/stage1/rts/build/c/linker/M32Alloc.thr_dyn_o _build/stage1/rts/build/c/linker/MMap.thr_dyn_o _build/stage1/rts/build/c/linker/MachO.thr_dyn_o _build/stage1/rts/build/c/linker/macho/plt.thr_dyn_o _build/stage1/rts/build/c/linker/macho/plt_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/PEi386.thr_dyn_o _build/stage1/rts/build/c/linker/SymbolExtras.thr_dyn_o _build/stage1/rts/build/c/linker/elf_got.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt_arm.thr_dyn_o _build/stage1/rts/build/c/linker/elf_reloc.thr_dyn_o _build/stage1/rts/build/c/linker/elf_reloc_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/elf_tlsgd.thr_dyn_o _build/stage1/rts/build/c/linker/elf_util.thr_dyn_o _build/stage1/rts/build/c/sm/BlockAlloc.thr_dyn_o _build/stage1/rts/build/c/sm/CNF.thr_dyn_o _build/stage1/rts/build/c/sm/Compact.thr_dyn_o _build/stage1/rts/build/c/sm/Evac.thr_dyn_o _build/stage1/rts/build/c/sm/Evac_thr.thr_dyn_o _build/stage1/rts/build/c/sm/GC.thr_dyn_o _build/stage1/rts/build/c/sm/GCAux.thr_dyn_o _build/stage1/rts/build/c/sm/GCUtils.thr_dyn_o _build/stage1/rts/build/c/sm/MBlock.thr_dyn_o _build/stage1/rts/build/c/sm/MarkWeak.thr_dyn_o _build/stage1/rts/build/c/sm/NonMoving.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingCensus.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingMark.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingScav.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingShortcut.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingSweep.thr_dyn_o _build/stage1/rts/build/c/sm/Sanity.thr_dyn_o _build/stage1/rts/build/c/sm/Scav.thr_dyn_o _build/stage1/rts/build/c/sm/Scav_thr.thr_dyn_o _build/stage1/rts/build/c/sm/Storage.thr_dyn_o _build/stage1/rts/build/c/sm/Sweep.thr_dyn_o _build/stage1/rts/build/c/fs.thr_dyn_o _build/stage1/rts/build/c/adjustor/NativeAmd64.thr_dyn_o _build/stage1/rts/build/c/posix/GetEnv.thr_dyn_o _build/stage1/rts/build/c/posix/GetTime.thr_dyn_o _build/stage1/rts/build/c/posix/Ticker.thr_dyn_o _build/stage1/rts/build/c/posix/OSMem.thr_dyn_o _build/stage1/rts/build/c/posix/OSThreads.thr_dyn_o _build/stage1/rts/build/c/posix/Select.thr_dyn_o _build/stage1/rts/build/c/posix/Signals.thr_dyn_o _build/stage1/rts/build/c/posix/TTY.thr_dyn_o _build/stage1/rts/build/cmm/Apply.thr_dyn_o _build/stage1/rts/build/cmm/Compact.thr_dyn_o _build/stage1/rts/build/cmm/Exception.thr_dyn_o _build/stage1/rts/build/cmm/HeapStackCheck.thr_dyn_o _build/stage1/rts/build/cmm/PrimOps.thr_dyn_o _build/stage1/rts/build/cmm/StgMiscClosures.thr_dyn_o _build/stage1/rts/build/cmm/StgStartup.thr_dyn_o _build/stage1/rts/build/cmm/StgStdThunks.thr_dyn_o _build/stage1/rts/build/cmm/Updates.thr_dyn_o _build/stage1/rts/build/cmm/AutoApply.thr_dyn_o -o _build/stage1/rts/build/libHSrts-1.0.2_thr-ghc9.3.20220217.so -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db -package-db=/home/nr/asterius/ghc/_build/stage1/lib/package.conf.d -ghcversion-file=rts/include/ghcversion.h -haddock -Irts -I_build/stage1/rts/build '-DRtsWay="rts_thr_dyn"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DTHREADED_RTS -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1

2 3

RE: Where do I put the *definition* of a DFunId?
by Erdi, Gergo 16 Feb '22

16 Feb '22

PUBLIC > I'm not surprised that eventually it crashes and burns, because, > again, I have only declared my DFunId ('$fShowOrderPolicy' in this > case), but never defined it. Its definition would be a CoreExpr, > right? So where would I put the pair of '(dfun, > myCoreExprOfTheRightType)' for GHC to pick it up? Or is it the case > that GHC would only need an 'Id's definition if it is trying to > inline/specialize it, i.e. should I just attach the definition to the > DFunId as an unfolding? Or is 'registerModule' already incomplete and > it should put the 'CoreProgram' of the module to somewhere deep in the > GHC state? I tried adding a reasonable-looking unfolding to the DFun, but I am still getting the same error when compiling code that uses the instance: $fShowOrderPolicy [InlPrag=CONLIKE] :: Show OrderPolicy [LclIdX[DFunId], Unf=DFun: \ -> C:Show \ _ [Occ=Dead] -> unpackCStringUtf8# "foo"# \ _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> unpackCStringUtf8# "bar"# \ _ [Occ=Dead] _ [Occ=Dead] -> unpackCStringUtf8# "baz"#] panic! (the 'impossible' happened) GHC version 9.3.20211130: lookupIdSubst $fShowOrderPolicy InScope {foo mapM_} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/GHC/Utils/Panic.hs:181:37 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Utils.Panic pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Core.Subst I have added a minimal working reproducer to https://gitlab.haskell.org/ghc/ghc/-/issues/21080 So the question remains, where do I need to put the DFun's definition (a CoreExpr of the right type) for it to be usable as an instance? Thanks, Gergo 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.

1 0

install stage0 libraries?
by Norman Ramsey 11 Feb '22

11 Feb '22

If I understand correctly, the way Hadrian works is that all of the .conf files, binaries, and so on in _build/stage0 are built with the bootstrap compiler. I need to write client code that uses the ghc library built from GHC HEAD (so ghc-9.3), but I'd prefer to use the bootstrap compiler. (The HLS works with the bootstrap compiler.) Is there a way to get Hadrian to install the stage0 libraries in a way that cabal-install can find it using standard options? I tried to do it myself using `ghc-pkg register`, and all I accomplished was to make an unrecoverable mess of my system. (The problem I'm trying to solve is to get my client code to compile against the latest library, while also enabling the HLS to find all the things.) Norman

1 0

Where do I put the *definition* of a DFunId?
by Erdi, Gergo 11 Feb '22

11 Feb '22

PUBLIC PUBLIC Hi, I'm trying to make a module out of thin air and register it to GHC so that other modules can import it. So far, I have had success with making a ModIface and a ModDetails, and then registering them using the following function: registerModule :: (GhcMonad m) => ModIface -> ModDetails -> m () registerModule iface details = modifySession $ extendHpt . addModule where mod_info = HomeModInfo iface details Nothing mod = mi_module iface modOrig = ModOrigin (Just True) [] [] True addModule = modifyUnitState $ \us -> us { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod modOrig) $ moduleNameProvidersMap us } extendHpt env = env { hsc_unit_env = let ue = hsc_unit_env env in ue { ue_hpt = hpt } } where hpt = addToHpt (hsc_HPT env) (moduleName mod) mod_info This worked when I was only _declaring_ functions and TyCons in these modules. However, now I would also like to add instances. And I'm hitting a problem here, because I don't know where to put the actual definitions of the instance. I'm completely lost here. Here's what I'm doing in detail. First, I make a fresh DFunId from a fresh Unique: let tag = occNameString . getDFunTyKey $ ty occ = mkDFunOcc (occNameString (getOccName showClass) <> tag) False emptyOccSet name = mkExternalName uniq mod occ loc dfun = mkDictFunId name [] [] showClass [ty] Then, I make a ClsInst that describes my instance: return ClsInst { is_cls_nm = getName showClass , is_tcs = [KnownTc $ getName tycon] , is_dfun_name = getName dfun , is_tvs = [] , is_cls = showClass , is_tys = [ty] , is_dfun = dfun , is_flag = OverlapFlag (NoOverlap NoSourceText) False , is_orphan = NotOrphan (getOccName $ getName tycon) } And then I add 'AnId dfun' to my ModDetails's type env in 'md_types',, add the instance to the 'md_insts', and fill the 'mi_decls' and 'mi_insts' of the ModIface accordingly. This gives me a ModIface/ModDetails pair just like before - but I never said what the definition of 'dfun' is! When I try compiling a real source module that imports this synthetic module and tries to use the instance, it gets as far as the "Desugar (after optimization)" step, and then fails with: ghc-mu-core-to-exp: panic! (the 'impossible' happened) GHC version 9.3.20211130: lookupIdSubst $fShowOrderPolicy InScope {foo mapM_} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/GHC/Utils/Panic.hs:181:37 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Utils.Panic pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Core.Subst I'm not surprised that eventually it crashes and burns, because, again, I have only declared my DFunId ('$fShowOrderPolicy' in this case), but never defined it. Its definition would be a CoreExpr, right? So where would I put the pair of '(dfun, myCoreExprOfTheRightType)' for GHC to pick it up? Or is it the case that GHC would only need an 'Id's definition if it is trying to inline/specialize it, i.e. should I just attach the definition to the DFunId as an unfolding? Or is 'registerModule' already incomplete and it should put the 'CoreProgram' of the module to somewhere deep in the GHC state? Thanks, Gergo 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.

3 3

the linters are killing me slowly
by Richard Eisenberg 10 Feb '22

10 Feb '22

Hi devs, Can we please, please not have the linters stop more useful output during CI? Over the past few months, I've lost several days of productivity due to the current design. Why several days? Because I typically end up with only 1.5-2 hours for GHC work in a day, and when I have to spend half of that recreating test results (which, sometimes, don't work, especially if I use Hadrian, as recommended), I often decide to prioritize other tasks that I have a more reasonable chance of actually finishing. It was floated some time ago that "Draft" MRs could skip linters. But I actually have a non-Draft MR now, and it failed the new Notes linter. (Why, actually, is that even a separate pass? I thought there was a test case for that, which I'm thrilled with.) It just feels to me that the current workflow is optimized for those of us who work on GHC close to 100% of the time. This is not the way to get new contributors. Frustrated, Richard

6 7