Re: Weird pipeline failures

Thanks! It seems all good now. On Tue, Aug 22, 2023, 18:45 Matthew Pickering wrote: > A bad commit made it into master (my fault) and I have now fixed this > and rebased your patch over it. > > Matt > > On Tue, Aug 22, 2023 at 7:19 AM Erdi, Gergo via ghc-devs > wrote: > > > > PUBLIC > > > > > >

Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library

Hi, A recent commit 983ce55815f2dd57f84ee86eee97febf7d80b470 starts using TemplateHaskellQuotes in the GHC codebase. It seems this is at odds with using GHC as a library, a la ghc-lib. The `ghc-lib` approach is to basically take the module hierarchy from the `compiler/` subtree, and compile i

Re: Partial type synonyms -- first-class!

That's great to hear because it looks like this will need all the support it can get to ever be allowed into upstream... On Fri, Aug 12, 2022, 10:43 Edward Kmett wrote: > FWIW, Gergo, I've been following what you've been doing pretty closely, so > there's at least two of us tracking it in the ba

Re: Partial type synonyms -- first-class!

I haven't heard back on this so I pushed ahead on the 3 outstanding problems by just applying more violence to the code base, basically. 1. For wildcard-originating type variables, I added a flag to the `TauTv` constructor of `MetaInfo`. The knock-on effects of this change were smaller than I expe

Re: Wildcards in type synonyms

So my idea from my last email is to avoid the need for `substHsTy`: When `tc_hs_type` encounters a macro occurrence, I would `tcLHsType` the rhs then and there (thereby getting fresh metas for each wildcard), use `substTy` to instantiate with the given type arguments. Then `tc_hs_type` returns tha

Re: Wildcards in type synonyms

Thanks Simon, these are very useful hints. My plan is to just push ahead on a separate fork, with this "macro semantics", and maybe if it comes out nicer than I'd hope, I'll propose it. So it seems that instead of shoehorning it into the existing type synonyms, a better bet would be to branch off

Warning about glomming

Using -DDEBUG, I see a warning about glomming from OccurAnal. Having read the relevant Note, the situation is exactly what's described here: since I'm using cross-module specializations, the specializer will generate rewrite rules that replace external references with local forward references. But

Re: Shadowing in toIface* output

So does that mean Tidy produces unique `occNameFS`s, and then `Prep` breaks them? On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith wrote: > > Hi, > > I encountered this when we used that for Plutus. I'll have to dig up the > details, but IIRC `toIfaceExpr` expects GHC to have already tidied the >

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 unfoldi

Re: Resources on how to implement (Haskell 98) kind checking?

Using mutable references for type metavariables is an implementation optimization: unifying a metavariable with a kind can then be cheaply implemented by replacing the metavar's content with the kind. After you are done with unification, you don't need metavariables anymore. If this were HM, you'd

Re: CI build failures

Thanks, this is all great news On Tue, Jul 27, 2021, 21:56 Ben Gamari wrote: > ÉRDI Gergő writes: > > > Hi, > > > > I'm seeing three build failures in CI: > > > Hi, > > > 1. On perf-nofib, it fails with: > > > Don't worry about this one for the moment. This job is marked as > accepting of failu

Re: CI build failures

The other two are resilient to restarts. On Tue, Jul 27, 2021, 18:49 Moritz Angermann wrote: > You can safely ignore the x86_64-darwin failure. I can get you the juicy > details over a beverage some time. It boils down to some odd behavior using > rosetta2 on AArch64 Mac mini’s to build x86_64 G

Re: Where else do I need to register fixity declarations?

Thanks, this works! I guess this is the kind of problems I run into by using `mkIface_` directly instead of via `mkIfaceTc`. Unfortunately, if I try that, I end up with a panic in `GHC.Iface.Recomp.mkHashFun` in my real program (see separate email earlier). On Tue, Jul 27, 2021, 16:14 Sylvain Hen

Re: Where else do I need to register fixity declarations?

I should add that I've also tried adding the just-loaded module to the EPS but that also doesn't fix the issue. On Tue, Jul 27, 2021, 15:14 Erdi, Gergo via ghc-devs wrote: > > > Hi, > > > > In the attached program, I am typechecking two Haskell modules with GHC > 9.0.1: `Imported.hs` defines som

Re: GHC 8.10 backports?

Thanks, that makes it less appealing. In the original thread, I got no further replies after my email announcing my "discovery" of that commit, so I thought that was the whole story. On Mon, Mar 22, 2021, 13:53 Viktor Dukhovni wrote: > On Mon, Mar 22, 2021 at 12:39:28PM +0800, Ger

Re: GHC 8.10 backports?

I'd love to have this in a GHC 8.10 release: https://mail.haskell.org/pipermail/ghc-devs/2021-March/019629.html On Mon, Mar 22, 2021, 12:34 Moritz Angermann wrote: > Hi there! > > Does anyone have any backports they'd like to see for consideration for > 8.10.5? > > Cheers, > Moritz > __