Re: [clash-language] Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

So if I understand correctly, OtherCon is only created here: https://gitlab.haskell.org/ghc/ghc/-/blob/a952dd80d40bf6b67194a44ff71d7bf75957d29e/compiler/GHC/Core/Opt/Simplify.hs#L3071-3077 simplAlt env _ imposs_deflt_cons case_bndr' cont' (Alt DEFAULT bndrs rhs) = assert (null bndrs) $ do {

Re: Alpha-equivalence for recursive let-bindings

imo...@microsoft.com will cease to work. Use simon.peytonjo...@gmail.com > instead. (For now, it just forwards to simo...@microsoft.com.) > > > > *From:* ghc-devs *On Behalf Of *Christiaan > Baaij > *Sent:* 07 November 2021 21:08 > *To:* ghc-devs > *Subject:* Alpha-equival

Alpha-equivalence for recursive let-bindings

Hi list, I was looking at the `Eq (DeBruijn CoreExpr)` instance and I noticed that the types of recursive let-bindings aren't checked for alpha-equivalence: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Core/Map/Expr.hs#L166-174 go (Let (Rec ps1) e1) (Let (Rec ps2) e2)

Re: GHC plugin authors?

Hi Richard, So there's multiple reasons/aspects as to why I haven't responded 1. Sam's question/seeking feedback on changing the return type for constraint solver plugins is something Sam and I discussed at HIW using ICFPs airmeet instance, as in, it was something I suggested. And the TL;DR of ne

Re: Trying to speedup GHC compile times...Help!

Somewhat off-topic: does GHC no longer use "the rapier"? I thought the InScopeSet was needed to check that we can safely skip on extending the substitution as you go under binders when the binder is not in the InScopeSet (naively you would always have to rename binders, and thus extend the substitu

Re: Writing GHC plugin to modify AST despite failure to type-check

Another option is to use a constraint solver plugin to "tag" the locations with a coercion, and then use a CorePlugin [1] to replace the corresponding cast by a call to liftIO. I've created a constraint solver plugin to tag all the locations here: https://gist.github.com/christiaanb/5e2412bffce0fef

Is there a way to prevent reboxing in W/W (due to OPAQUE pragma proposal)

Hi Ghc-Devs, I believe I've mostly finished the implementation of GHC proposal 0415 [1], the OPAQUE pragma, over at: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562 The only remaining issue is that I'm unsure whether there's a way to prevent reboxing of worker arguments as witnessed here

Re: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

gt; > Simon > > > > *From:* ghc-devs *On Behalf Of *Christiaan > Baaij > *Sent:* 17 June 2021 10:44 > *To:* ghc-devs > *Subject:* Error message degradation for (<= :: Nat -> Nat -> Constraint) > in GHC 9.2+ > > > > Hi Ghc-Devs, > >

Re: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

(Compare a b) 'True 'True 'False ``` I realize this is far from ideal On Thu, 17 Jun 2021 at 14:46, Adam Gundry wrote: > Hi Christiaan, > > > On 17/06/2021 10:43, Christiaan Baaij wrote: > > [...] > > > > Errors messages involving type-level natural

Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

Hi Ghc-Devs, When upgrading one of our tc plugins https://hackage.haskell.org/package/ghc-typelits-natnormalise to GHC 9.2, one of our tests, repeated here: ``` {-# LANGUAGE DataKinds, TypeFamilies, TypeOperators #-} module TestInEq where import Data.Proxy import GHC.TypeLits proxyInEq :: (a <=

Re: Rewriting plugins: request for feedback

Hi Sam, Thanks for picking this up, the API looks good so far. I'll try to port our https://hackage.haskell.org/package/ghc-typelits-extra package to the new API. Though first I need to upgrade https://hackage.haskell.org/package/ghc-typelits-natnormalise to the GHC 9.2+ API, which is got somewha

Re: What changed between GHC 8.8 and 8.10 that could cause this?

nker <- ... > runGhc .. $ do >setSession $ hsc_env { hsc_dynLinker = shared_linker } > > > Should restore the behavior. You don't need to run inside a single runGhc, > you just need to provide a single hsc_dynLinker. > > That should work. > > Kind Regards,

Re: What changed between GHC 8.8 and 8.10 that could cause this?

lying on behavior we explicitly stated is not the case is > a bug in Clash. > > If you require shared state you should not be using the top level runGhc > wrapper but instead call unGhc yourself (or call setSession yourself). > > There is perhaps a case to be made for a runGhcShare

Re: What changed between GHC 8.8 and 8.10 that could cause this?

Even if MR388 ( https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388 ) is the cause of the issue we're seeing with the API exposed by Clash, I still think MR388 is wrong. My reasoning is the following: In 8.8 and earlier we had: - RTS C-code contains the ground truth of what is linked. The API

Re: Find the ghc binary path from libdir

Calling `ghc --print-lib-dir` is the only way because the `$libdir` is actually provided on the cmdline using the -B flag: https://gitlab.haskell.org/ghc/ghc/-/blob/master/ghc/Main.hs#L110-112 That's why the `ghc` you normally execute is a shell-wrapper around the `ghc` executable applied to a `-B

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

ave a satisfactory solution, perhaps consider it for inclusion in the `ghc` package.) This way, we won't have to make the common case of simplifying type families slow, and still provide a straightforward API. On Mon, 30 Nov 2020 at 20:03, Richard Eisenberg wrote: > > > On Nov 30,

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

This Note ( > https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678) > is the best I can offer, though it may be out of date. In the final version > of the patch, that Note will naturally be updated. Essentially, the new > plan is just to u

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

I always forget what flattening did/does. Is it the thing where it turns a "complex" type family application: F (G y) (H z) ~ a into: G y ~ p H z ~ q F p q ~ a ? If so, then I'm all for removing that. Since I actually wrote/hacked a function that "reverts" that process (for [G]ivens only): htt

Re: Use of forall as a sigil

Reading proposal 281, I would be similarly confused. In point 4 of section 4.1, primary change, it states that type constructors are now allowed in the grammar of patterns; which if I understand correctly is mostly a name-resolving thing. Perhaps I read the proposal too quickly, but I couldn't fin

Re: Class op rules

because of the always bottoming) it gets rewritten to `test1 _ = case fromList' of {}` On Sat, 7 Mar 2020 at 02:56, Dr. ÉRDI Gergő wrote: > As a workaround, can you try this? > https://stackoverflow.com/a/32133083/477476 > > On Fri, Mar 6, 2020, 23:23 Christiaan Baaij > wr

Re: Class op rules

selector. > > > > I remember Conal raising this before, but I’ve forgotten the resolution. > I’m entirely open to changes here, if someone is willing to do the work, > including checking for consequences. > > > > Simon > > > > *From:* ghc-devs *On Behalf

Re: Typechecker plugin proposal, ticket #15147

I actually have conflicting needs: 1. ghc-typelits-natnormalise, a solver for type-level Nat equations, would benefits from both unflattened givens and unflattened wanteds! Why unflattened givens? because from `[G] 2*x + a ~ 2*x + b` I can derive `a ~ b` Which I could then use to solve: [W] 3*y + a

Class op rules

Hello, The other day I was experimenting with RULES and got this warning: src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing] Rule "map Pack" may never fire because rule "Class op pack" for ‘pack’ might fire first Probable fix: add phase [n] or [~n] to the competin

type-checker plugin API/behaviour change

Hi devs, Currently, type-checker plugins get to tell the solver its progress using a [TcPluginResult]( http://hackage.haskell.org/package/ghc-8.4.1/docs/TcRnTypes.html#t:TcPluginResult ): ``` data TcPluginResult = TcPluginContradiction [Ct] -- ^ The plugin found a contradiction. -- The

Re: Accessing 'Annotations' of modules in external packages

ghc-devs is probably a better location for GHC API questions. Anyhow, you might want to look at some code in the Clash compiler: https://github.com/clash-lang/clash-compiler/blob/6ec3ca426bfaaaddcd3692775c25614bc19482fa/clash-ghc/src-ghc/Clash/GHC/LoadInterfaceFiles.hs#L168-L225 We use that to fin

Re: GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions

I've created a ticket for this at: https://ghc.haskell.org/trac/ghc/ticket/13663 On 8 May 2017 at 16:12, Ben Gamari wrote: > Christiaan Baaij writes: > > > Hello GHC Devs, > > > Hi! > > > So my question are: > > - Which part of the simplifier is tu

GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions

Hello GHC Devs, First some context: I'm using the GHC API to convert Haskell to digital circuit descriptions (clash compiler). When viewed as a structural description of a circuit, recursive let-bindings can be turned into feedback loops. In general, when viewed as a structural description of a ci

Re: Specialization plugin

One small question: what's the difference between adding INLINABLE everywhere, and just compiling with -fexpose-all-unfoldings, https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using-optimisation.html#ghc-flag--fexpose-all-unfoldings? Is there any reason you couldn't use that flag as

Re: Why upper bound version numbers?

Given that I'm the maintainer of the 'clash' package, I wanted to say that the 'clash' package has been deprecated in favour of the 'clash-ghc' package (for some time now, and this is stated on hackage). Sadly, 'clash-ghc' will not compile on ghc 8.0.1 right now either; it only compiles agains

Re: TH changes for ghc 8.0

mapM conT :: [Name] -> Q [Type] :: [Name] -> Q [Pred] :: [Name] -> CxtQ Those `Name`s are Class names, which are Type constructors, hence `conT` Christiaan On 04/12/2016 10:17 AM, Erik de Castro Lopo wrote: Erik Hesselink wrote: That function does exist for me in rc2: cxt :: [PredQ] -> CxtQ

Re: How to prevent GHC (API) from breaking large constants into multiple top-level bindings

ng. But surely it should be a linear-time substitution to undo it? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Christiaan Baaij | Sent: 24 March 2016 13:39 | To: ghc-devs@haskell.org | Subject: How to prevent GHC (API) from brea

How to prevent GHC (API) from breaking large constants into multiple top-level bindings

My situation is the following, given the code: > {-# LANGUAGE GADTs, DataKinds, TypeOperators, KindSignatures #-} > module GConst where > > import GHC.TypeLits > > data Vec :: Nat -> * -> * > where > Nil :: Vec 0 a > Cons :: a -> Vec n a -> Vec (n+1) a > > infixr `Cons` > > c :: Vec 5

Re: GHC 8.0.1 status

Given that I was working on at least once package ( https://github.com/goldfirere/singletons/pull/142) which gave panics on GHC8-rc2, couldn't we get at least an GHC8-rc3 before doing an 8.0.1 release in 3 weeks? On 27 February 2016 at 14:57, Ben Gamari wrote: > tl;dr. Stabilizing the ghc-8.0 is

Re: Duplicated typedef trips my gcc over

I cannot build HEAD for the same reason. Same GCC version. On 21 October 2015 at 13:08, Gabor Greif wrote: > Hi all, > > look: > > $ git grep "typedef struct LibDwSession_ " > rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; > rts/Libdw.h:typedef struct LibDwSession_ LibDwSession; > > $ wh

Fwd: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args

Forgot to also send to the list > Begin forwarded message: > > From: Christiaan Baaij > Subject: Re: Strictness/demand analysis without worker/wrapper, or, reviving > -fmax-worker-args > Date: 15 Oct 2015 17:27:21 CEST > To: Simon Peyton Jones > > Thanks for th

Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args

Hi, As a GHC API user, I would like to run GHC’s strictness and demand analysis pass, but I don’t want any worker/wrappers. My specific use-case is to generate digital circuits from Haskell code, where I’ve yet to encounter any benefit from worker/wrappers: the generated circuits do not get any

Re: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD

> Beyond the changes in Phab:D909, the only thing I'm still using > unsafeTcPluginTcM for is newUnique (in order to generate new skolem > variables), which could easily be added to the TcPluginM interface as > well. Anyone need anything else? No, In my own type-checker plugins I only use unsafeTc

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)

Hi, This patch causes a regression from GHC 7.10 with regards to constraint kinds. Where previously, constraint tuples could go up to 62, the same as normal tuples, they have now been reduced to 8. I filed a bug report at: https://ghc.haskell.org/trac/ghc/ticket/10451

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)

Hi, This patch broke the ‘Binary’ instance for ‘IfaceType’ in ‘iface/IfaceType.hs’ Specifically, it changed: ``` put_ bh (IfaceLitTy n) = do { putByte bh 30; put_ bh n } ``` to: ``` put_ bh (IfaceLitTy n) = do { putByte bh 7; put_ bh n } ``` However, the ‘get’ definition was left as: ``

Re: Interactions between type-checker plugins

ved the original constraint. — Christiaan > On 19 May 2015, at 18:44, Christiaan Baaij wrote: > > I have yet to test this properly, but I don't think your suggestions (which > you happen to give with 1 minute of eachother...) play nicely with error > reporting. > Here is an ou

Re: Interactions between type-checker plugins

though, the plugin can actually commit to the > given path because the only way to solve "GCD 6 8 + x ~ x + GCD 9 6" is if > "GCD 6 8 ~ GCD 9 6". So I'd imagine you want these steps: > > Plugin A: Solve "GCD 6 8 + x ~ x + GCD 9 6", new wanted "

Interactions between type-checker plugins

Hi, My apologies for this rather lengthy email. I have a question about how type-checker plugins should interact. My situation is the following: I have two type-checker plugins, one that can solve equalities involving the standard type-level operations on kind Nat (+,*,-,^), and another type-che

Re: Current description of Core?

> Perhaps slightly off-topic. > I have looked at the core-spec document, and had a question regarding the > operational semantics part. > > Given the Core expressions: >> case (let r = 1 : r in r) of (x:xs) -> x > > An interpreter following the semantics would loop on the above expression, as

Re: Current description of Core?

Perhaps slightly off-topic. I have looked at the core-spec document, and had a question regarding the operational semantics part. Given the Core expressions: > case (let r = 1 : r in r) of (x:xs) -> x An interpreter following the semantics would loop on the above expression, as the S_LetRecRetu

Re: Call for help on testing integer-gmp2 on non-Linux archs

The testsuite results are here: http://paste.ubuntu.com/7836630/ On Jul 22, 2014, at 2:11 PM, Christiaan Baaij wrote: > Starting a build on my MAC: > > OS: 10.8.5 > XCode: XCode 4 CLI-only (so _no_ full Xcode, that is, xcode-select fails) > GCC: i686-apple-darwin11-llvm-gcc-

Re: Call for help on testing integer-gmp2 on non-Linux archs

Starting a build on my MAC: OS: 10.8.5 XCode: XCode 4 CLI-only (so _no_ full Xcode, that is, xcode-select fails) GCC: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) GHC: 7.8.3 On Jul 22, 2014, at 2:02 PM, Herbert Valerio Riedel wrote: > On

Re: Many new validate failures, "Synonym in TyConAppCo"-related

I see that the core-lint patch calls: > -- | Is this a 'TyCon' representing a type synonym (@type@)? > isSynTyCon :: TyCon -> Bool > isSynTyCon (SynTyCon {}) = True > isSynTyCon _ = False And from simon's comments it seems like he only wanted to check for "normal" type synonyms. 'isS

Why is an irrefutable pattern desugared to a 'cast', while an incomplete pattern is not?

Dear list, When I ask for the desugaring of: > module PatError where > > paterror :: Maybe Int -> Int > paterror (Just i) = i I get the following: > PatError.paterror = > \ (ds_dIS :: Data.Maybe.Maybe GHC.Types.Int) -> > break<1>() > case ds_dIS of _ [Occ=Dead] { > __DEFAULT -> >

Re: Breaking bug in 7.8.1

It seems kinda to late to mention… but the release notes don't say that pattern splices are now supported in Template Haskell. A "big" new feature for Template Haskell I would say, and worthy of mentioning in the release notes. But perhaps for 7.8.3? -- Christiaan On Apr 10, 2014, at 3:42 PM, Aus

Re: TypeNats trial on new ghc branch 7.8

The "simplified" solver, as in https://github.com/ghc/ghc/tree/type-nats-simple, has been integrated as far as I know. I've been experimenting with my own solver: https://gist.github.com/christiaanb/8396614 Here are some examples of the stuff that works with my solver: https://github.com/christiaan

Re: Validate broken on Snow Leopard and Mountain Lion

001 [stat too good] >> (hpc,optasm,dyn,optllvm) >> polykinds T6068 [bad stderr] (ghci) >> rts T7919 [exit code non-0] >> (normal,hpc,optasm,threaded1,threaded2,optllvm) >> th/TH_import_loop TH_import_loop [bad stdout o

Re: Validate broken on Snow Leopard and Mountain Lion

tderr] (normal,hpc,optasm,threaded1,threaded2,dyn,optllvm) typecheck/should_runT7861 [bad stdout or stderr] (ghci) On Nov 14, 2013, at 12:04 PM, Christiaan Baaij wrote: > After fixing the warning in the C-code of the primitive package, validate > (including dph tests) seems

Re: Validate broken on Snow Leopard and Mountain Lion

need to take more seriously. > > > > > On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier wrote: > > On 13/11/2013, at 8:02 PM, Christiaan Baaij wrote: > > > Does validate work for the DPH packages on Linux? > > "sh validate" runs fine on my Linux mac

Re: Validate broken on Snow Leopard and Mountain Lion

> really really broken between releases is probably the single HUGEST barrier > to more people getting involved in helping GHC dev. And I think thats a huge > problem we need to take more seriously. > > > > > On Wed, Nov 13, 2013 at 11:09 PM, Ben Lippmeier wrote: &g

Re: Validate broken on Snow Leopard and Mountain Lion

The error in snow leopard is the result of my patch [1] for #8266 [2], which ensures that the original build directory is no longer referenced in installed packages/libs. The patch is just a proper implementation of the original design though. Perhaps the "relative-dynlib-references" procedure s

Re: [commit: packages/base] master: Expose performMinorGC (#8257) (c1491e6)

Shouldn't the last line of the patch be?: > +foreign import ccall "performGC" performMinorGC :: IO () the rts doesn't export a function called "performMinorGC". -- Christiaan On Sep 30, 2013, at 12:24 AM, g...@git.haskell.org wrote: > Repository : ssh://g...@git.haskell.org/base > > On branch

Re: Executables using GHC API require dynamic linking in GHC 7.7

relevant information there > in. That is the best way to promptly get folks to see it > > -Carter > > > On Saturday, September 28, 2013 at 2:55 AM, Christiaan Baaij wrote: > >> Yes, I have both the static libs and the dynamic libs. >> So for every library I have bo

Fixing 8266: How do I get a list of all dist-install/build directories?

Hello everyone, I'm trying to write a patch for #8266. Here's what I have so far: https://gist.github.com/christiaanb/6648192 It changes the name of the dynamic library to a relative path instead of an absolute one. However, now I'm getting an error while building the DPH packages (probably due