From shayne.fletcher.50 at gmail.com Sun Jun 2 16:50:48 2024 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Sun, 2 Jun 2024 12:50:48 -0400 Subject: sempahore-compat-1.0.0 base bounds Message-ID: the bounds for semaphore-compat-1.0.0 do not include base-4.20. can this be fixed please? -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Mon Jun 3 09:12:00 2024 From: sylvain at haskus.fr (Sylvain Henry) Date: Mon, 3 Jun 2024 11:12:00 +0200 Subject: RTS crashes In-Reply-To: References: Message-ID: Which build flavour are you using? Are you enabling assertions only in the RTS? > This can't possibly be my fault!   I don't know if CI perhaps has these assertion switched off, so only I am seeing them? Compiler performance tests are disabled in debug builds, cf testsuite/driver/testlib.py:     # Compiler performance numbers change when debugging is on, making the results     # useless and confusing. Therefore, skip if debugging is on.     if config.compiler_debugged and is_compiler_stats_test:         opts.skip = True That could explain why we don't see this on CI in slow-validate jobs. Sylvain On 31/05/2024 12:43, Simon Peyton Jones wrote: > In my private build of !12492 I'm getting some assertion failures in > CheckUnload (see below). > > This can't possibly be my fault!   I don't know if CI perhaps has > these assertion switched off, so only I am seeing them? > > I'd open a ticket but it may just be my bad, somehow > > Any ideas? > > Simon > > > Stderr  run  ( MultiLayerModulesDefsGhci ): > ghc: internal error: ASSERTION FAILED: file rts/CheckUnload.c, line 460 > >     (GHC version 9.11.20240530 for x86_64_unknown_linux) >     Please report this as a GHC bug: > https://www.haskell.org/ghc/reportabug > Aborted > *** unexpected failure for MultiLayerModulesDefsGhci(ghci) > ]0;MultiLayerModulesDefsGhciReload(ghci) 4776 of 10144 [0, 1, 0] > ]0;InstanceMatching(normal) 4777 of 10144 [0, 1, 0] ]0;Running for > 5m51s [35433/36451], predicted 1s (98%) Wrong exit code for > MultiLayerModulesDefsGhciReload(ghci)(expected 0 , actual 134 ) > Stderr  run  ( MultiLayerModulesDefsGhciReload ): > ghc: internal error: ASSERTION FAILED: file rts/CheckUnload.c, line 460 > >     (GHC version 9.11.20240530 for x86_64_unknown_linux) >     Please report this as a GHC bug: > https://www.haskell.org/ghc/reportabug > Aborted > *** unexpected failure for MultiLayerModulesDefsGhciReload(ghci) > ]0;InstanceMatching1(normal) 4778 of 10144 [0, 2, 0] > ]0;MultiLayerModulesNoCode(ghci) 4779 of 10144 [0, 2, 0] Wrong exit > code for MultiLayerModulesNoCode(ghci)(expected 0 , actual 134 ) > Stderr  run  ( MultiLayerModulesNoCode ): > ghc: internal error: ASSERTION FAILED: file rts/CheckUnload.c, line 460 > >     (GHC version 9.11.20240530 for x86_64_unknown_linux) >     Please report this as a GHC bug: > https://www.haskell.org/ghc/reportabug > Aborted > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukewtollefson at gmail.com Wed Jun 5 12:59:47 2024 From: lukewtollefson at gmail.com (Luke Tollefson) Date: Wed, 5 Jun 2024 14:59:47 +0200 Subject: GitLab Approval Message-ID: Hey! I'm looking to get my GitLab account approved for the ZuriHac workshop. Username: lukewtollefson Thanks! Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Jun 5 15:43:11 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 5 Jun 2024 11:43:11 -0400 Subject: GitLab Approval In-Reply-To: References: Message-ID: Approved, sorry for the delay. On Wed, Jun 5, 2024 at 9:00 AM Luke Tollefson wrote: > Hey! I'm looking to get my GitLab account approved for the ZuriHac > workshop. Username: lukewtollefson > > Thanks! > Luke > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From teofilcamarasu at gmail.com Thu Jun 6 18:09:48 2024 From: teofilcamarasu at gmail.com (Teofil Camarasu) Date: Thu, 6 Jun 2024 19:09:48 +0100 Subject: Blog post: working towards a more stable Template Haskell Message-ID: Hi folks, I’ve written up a blog post about our ongoing project to improve the stability of Template Haskell. The post lays out: - why users of Template Haskell often face broken code with each new version of the compiler. - some of our plans to make the interface more stable. - some groundwork we’ve lain to make these plans achievable - ways folks can get invovled Give it a read: https://informal.codes/posts/stabilising-th/ Cheers, Teo -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Fri Jun 7 08:40:30 2024 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Fri, 7 Jun 2024 10:40:30 +0200 Subject: Blog post: working towards a more stable Template Haskell In-Reply-To: References: Message-ID: As someone who considers these issues some of the most important that the Haskell ecosystem is facing right now: thank you very much for leading this. On Thu, 6 Jun 2024 at 20:10, Teofil Camarasu wrote: > Hi folks, > > I’ve written up a blog post about our ongoing project to improve the > stability of Template Haskell. > > The post lays out: > > - why users of Template Haskell often face broken code with each new > version of the compiler. > - some of our plans to make the interface more stable. > - some groundwork we’ve lain to make these plans achievable > - ways folks can get invovled > > Give it a read: > https://informal.codes/posts/stabilising-th/ > > Cheers, > > Teo > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoorv-ingle at uiowa.edu Fri Jun 7 22:08:10 2024 From: apoorv-ingle at uiowa.edu (Ingle, Apoorv N) Date: Fri, 7 Jun 2024 22:08:10 +0000 Subject: Changes to HIE File due to ApplicativeDo going via HsExpansions Message-ID: <542430EC-512F-4128-B635-A275A25BCB58@uiowa.edu> Dear ghc-devs, For past few months I’ve been working on Rebindable Syntax, specifically on expanding ApplicativeDo (#24406, MR !12066) statements before type checking. I noticed that there is a failing test case related to HIE files (T23540). I have been unsuccessful in debugging why this happens and/or if this has any effect on the users of HIE files. Can anyone who has experience in this area be able to take a look and guide me? Thanks! Apoorv -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Sun Jun 9 11:45:40 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Sun, 9 Jun 2024 13:45:40 +0200 Subject: Changes to HIE File due to ApplicativeDo going via HsExpansions In-Reply-To: <542430EC-512F-4128-B635-A275A25BCB58@uiowa.edu> References: <542430EC-512F-4128-B635-A275A25BCB58@uiowa.edu> Message-ID: <52bm3bsqau7pknb6kfkcawljzlzthfqyujogdz67nhqekdntnn@5mtqfln5m7sg> This looks like a genuine regression, that test attempts to print out the evidence of the monad constraint necessary to call the implicit (>>=) in the do block. I think to fix this you need to ensure that GHC.Iface.Ext.Ast is able to traverse into the part of the typechecked AST that corresponds to the desugared/expanded statements, so that it can see the calls to (>>=) that are implicit in the AST. On 24/06/07 22:08, Ingle, Apoorv N via ghc-devs wrote: >Dear ghc-devs, > >For past few months I’ve been working on Rebindable Syntax, specifically on expanding ApplicativeDo (#24406, MR !12066) statements before type checking. >I noticed that there is a failing test case related to HIE files (T23540). I have been unsuccessful in debugging why this happens and/or if this has any effect on the users of HIE files. > >Can anyone who has experience in this area be able to take a look and guide me? > >Thanks! >Apoorv >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From bryan at haskell.foundation Mon Jun 10 13:42:59 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 10 Jun 2024 15:42:59 +0200 Subject: A dashboard for fragile tests Message-ID: Hi all, This weekend at Zurihac, I wanted to start making it possible to explore fragile tests. Fragile tests are tests that pass nondeterministically. Marking them fragile means that they do not influence the overall success of the testsuite. It's been a way of sweeping problems under the rug. For a few years, the GHC test infrastructure has been recording fragile test results into a database. We record whether the test passed or failed. Now we can start peeking under the rug to see what kind of patterns have developed. I was mostly interested in whether or not fragile tests are truly fragile. It looks like many are not. The dashboard has bucketed results into months. Every cell shows the pass rate for a given month (column) and test (row). Red cells mean 0% success. Green cells, 100% success. Shades of yellow are everything in between. It's remarkable how much green there is. One would assume even fragile tests would fail for legitimate reasons sometimes! At this point, the visualization is mostly good for seeing large trends. Any other observations would be appreciated! The dashboard is interactive at https://grafana.gitlab.haskell.org/goto/XcuO3ZUIg?orgId=2 [image: image.png] -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 65895 bytes Desc: not available URL: From shayne.fletcher.50 at gmail.com Fri Jun 14 00:59:15 2024 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Thu, 13 Jun 2024 17:59:15 -0700 Subject: embedded hashes in library names Message-ID: when i use ghcup to install a distribution, the libraries that result have embedded hashes in their names e.g. the -f942 in libHSghc-prim-0.11.0-f942-ghc9.10.1.so. is there some way to disable this so that for example in this case, i'd get libHSghc-prim-0.11.0-ghc9.10.1.so? -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher.50 at gmail.com Fri Jun 14 01:30:52 2024 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Thu, 13 Jun 2024 18:30:52 -0700 Subject: embedded hashes in library names In-Reply-To: References: Message-ID: never mind, i realize now how this works :) On Thu, Jun 13, 2024 at 5:59 PM Shayne Fletcher < shayne.fletcher.50 at gmail.com> wrote: > when i use ghcup to install a distribution, the libraries that result have > embedded hashes in their names e.g. the -f942 in > libHSghc-prim-0.11.0-f942-ghc9.10.1.so. is there some way to disable this > so that for example in this case, i'd get > libHSghc-prim-0.11.0-ghc9.10.1.so? > > -- > Shayne Fletcher > -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Jun 18 15:43:35 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 18 Jun 2024 16:43:35 +0100 Subject: TTG and annotations Message-ID: Hi Alan I know that you are continuing to work hard on annotations in the TTG extension fields -- thank you. As you know, I'm very eager to get a big Note to explain how it all works. At the moment I am completely lost, and I am reduced to cargo-culting code by copy/pasting and hoping for the best. Plus we are over-reliant on you, which isn't really fair on you. Several of us (including me and Rodrigo, and doubtless other ghc-devs, cc'd) would be happy to review, edit, and improve -- but it is hard for us to see the "big picture". Could you see your way to drafting something? It need not be that long initially, but having *something* to ask questions about and improve would be super helpful. I suggest drafting it in a Google doc so it was easy to edit, and for others to contribute to, but ultimately it should be in the repo. Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Wed Jun 19 08:52:01 2024 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Wed, 19 Jun 2024 08:52:01 +0000 Subject: Deriving via TH (#12457) Message-ID: Hi Ryan and GHC devs, I'm working on-and-off on a prototype that enables use of TemplateHaskell as a deriving strategy: https://gitlab.haskell.org/ghc/ghc/-/commit/82aea77ed908fe36bed829c9c4a01ea9b30a0181. My current working example is: ``` {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module T12457A where import GHC.Internal.TH.Lib import GHC.Internal.TH.Syntax class C a where type Assoc a m :: a -> Int n :: a -> Int instance DeriveTH C where deriveTH _p head = do let AppT (ConT t) (VarT a) = head x <- newName "x" x2 <- newName "x" addTopDecls =<< [d| $(varP x) = 12 $(varP x2) = 23 |] [d| instance C $(varT a) => C ($(conT t) $(varT a)) where type Assoc ($(conT t) $(varT a)) = Char m :: Eq a => a -> Int m _ = $(varE x) + 42 {-# INLINE m #-} n :: Show a => a -> Int n _ = $(varE x2) + 13 |] --- {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DerivingStrategies #-} module T12457 where import Language.Haskell.TH import GHC.Internal.TH.Lib import T12457A newtype T a = T [a] deriving th C ``` I just managed to implement `GHC.Tc.Deriv.Infer.inferConstraints` for this mechanism (still hacky and broken in many ways) and am now stuck in `Deriv.genFamInst`. I realised I would need to replicate the first half of `tcClsInstDecl` to implement it. Before long, I will probably also need to replicate the other half to check method bindings. That leaves me wondering: Is it a good idea to integrate this new deriving strategy so tightly with the existing deriving framework? I would rather just call `tcClsInstDecl`, do a bit of sanity checking for specified constraints in standalone deriving declarations and call it a day. Given that you are the architect of our current deriving code, I hope you are the right person to ask for input. Thanks, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Jun 19 13:07:47 2024 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 19 Jun 2024 09:07:47 -0400 Subject: Deriving via TH (#12457) In-Reply-To: References: Message-ID: Hi Sebastian, This is exciting! I haven't taken a close look at the implementation, but here are my initial reactions: - The implementation of `deriving` proceeds in a somewhat unusual way: you first typecheck the `deriving` clause and use the resulting Core types to figure out what the instance head should be. Then, you generate the method bindings for the instance as parsed code, then proceed to rename and typecheck the bindings. As such, `deriving` goes from typechecking -> renaming -> typechecking, which is somewhat odd... - ...and derived type family instances work in an even more odd way. Rather than generating parsed type family instance declarations (and then renaming/typechecking them), `deriving` directly generates Core axioms for the instances. As such, derived associated type family instances go through a rather different code path than derived method bindings. (There are technical reasons why this is the case, but I won't get into them here.) This asymmetry means that the existing `deriving` machinery has to do some odd things to make everything fit together. - I think part of the difficulty you're encountering is that the `th` deriving strategy is attempting to produce associated type family instances from TH quotes (i.e., parsed code), rather than from typechecked code. Every other deriving strategy produces its associated type family instances from Core types, however, so they are able to generate instances without renaming or typechecking. You don't have that luxury. As such, I agree that you'll need to reuse other parts of the renamer and typechecker (e.g., the `tcClsInstDecl` function) in order to turn your TH-quoted type family instances into Core axioms. - Is it a good idea to integrate this new deriving strategy so tightly with the existing deriving framework? I think it's at least worth trying. The `deriving` code path is *just* different enough from the code path for ordinary class instances where I think you'll encounter some oddities if you try to implement the `th` deriving strategy out of band. For example, you'll want to be able to dump `th`-derived code that you generate using -ddump-deriv, which currently only happens in the `deriving` code path. I suppose you could change things so that -ddump-deriv does things in multiple places in the code, but I worry that that may lead to an uncomfortable amount of code duplication. (Not to mention that you'll have to be careful to actually emulate everything that the `deriving` code path does, because if you forget something, then that can lead to confusing bugs down the road.) - Of course, I won't claim that the current design of the `deriving` code path is perfect by any means. If there are ways we could clean things up that would make it easier to implement the `th` deriving strategy, then we should consider doing that. I'm not sure if I fully answered the spirit of your question, so feel free to ask follow-up questions with specifics if I missed the mark. Best, Ryan On Wed, Jun 19, 2024 at 4:52 AM Sebastian Graf wrote: > Hi Ryan and GHC devs, > > I'm working on-and-off on a prototype that enables use of TemplateHaskell > as a deriving strategy: > https://gitlab.haskell.org/ghc/ghc/-/commit/82aea77ed908fe36bed829c9c4a01ea9b30a0181 > . > My current working example is: > > ``` > {-# LANGUAGE TemplateHaskell #-} > {-# LANGUAGE TypeFamilies #-} > > module T12457A where > > import GHC.Internal.TH.Lib > import GHC.Internal.TH.Syntax > > class C a where > type Assoc a > m :: a -> Int > n :: a -> Int > > instance DeriveTH C where > deriveTH _p head = do > let AppT (ConT t) (VarT a) = head > x <- newName "x" > x2 <- newName "x" > addTopDecls =<< [d| > $(varP x) = 12 > $(varP x2) = 23 |] > [d| > instance C $(varT a) => C ($(conT t) $(varT a)) where > type Assoc ($(conT t) $(varT a)) = Char > m :: Eq a => a -> Int > m _ = $(varE x) + 42 > {-# INLINE m #-} > n :: Show a => a -> Int > n _ = $(varE x2) + 13 |] > > --- > > {-# LANGUAGE TemplateHaskell #-} > {-# LANGUAGE ConstraintKinds #-} > {-# LANGUAGE DerivingStrategies #-} > > module T12457 where > > import Language.Haskell.TH > import GHC.Internal.TH.Lib > import T12457A > > newtype T a = T [a] deriving th C > ``` > > I just managed to implement `GHC.Tc.Deriv.Infer.inferConstraints` for this > mechanism (still hacky and broken in many ways) and am now stuck in > `Deriv.genFamInst`. > I realised I would need to replicate the first half of `tcClsInstDecl` to > implement it. Before long, I will probably also need to replicate the other > half to check method bindings. > That leaves me wondering: Is it a good idea to integrate this new deriving > strategy so tightly with the existing deriving framework? > I would rather just call `tcClsInstDecl`, do a bit of sanity checking for > specified constraints in standalone deriving declarations and call it a day. > > Given that you are the architect of our current deriving code, I hope you > are the right person to ask for input. > > Thanks, > Sebastian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Wed Jun 19 15:21:33 2024 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Wed, 19 Jun 2024 15:21:33 +0000 Subject: Deriving via TH (#12457) In-Reply-To: References: Message-ID: Hi Ryan, Thank you for such a detailed reply! What you wrote gave me confidence in just duplicating code from `tcClsInstDecl`. The code is a bit of mess now because the tyvars chosen for the `deriving` instance head might not match with the tyvars used returned in the splice, but I think we can sort this out during review once we have a running prototype. Sebastian ------ Originalnachricht ------ Von "Ryan Scott" An "Sebastian Graf" Cc "GHC developers" Datum 19.06.2024 15:07:47 Betreff Re: Deriving via TH (#12457) >Hi Sebastian, > >This is exciting! I haven't taken a close look at the implementation, >but here are my initial reactions: >The implementation of `deriving` proceeds in a somewhat unusual way: >you first typecheck the `deriving` clause and use the resulting Core >types to figure out what the instance head should be. Then, you >generate the method bindings for the instance as parsed code, then >proceed to rename and typecheck the bindings. As such, `deriving` goes >from typechecking -> renaming -> typechecking, which is somewhat odd... >...and derived type family instances work in an even more odd way. >Rather than generating parsed type family instance declarations (and >then renaming/typechecking them), `deriving` directly generates Core >axioms for the instances. As such, derived associated type family >instances go through a rather different code path than derived method >bindings. (There are technical reasons why this is the case, but I >won't get into them here.) This asymmetry means that the existing >`deriving` machinery has to do some odd things to make everything fit >together. >I think part of the difficulty you're encountering is that the `th` >deriving strategy is attempting to produce associated type family >instances from TH quotes (i.e., parsed code), rather than from >typechecked code. Every other deriving strategy produces its associated >type family instances from Core types, however, so they are able to >generate instances without renaming or typechecking. You don't have >that luxury. As such, I agree that you'll need to reuse other parts of >the renamer and typechecker (e.g., the `tcClsInstDecl` function) in >order to turn your TH-quoted type family instances into Core axioms. >Is it a good idea to integrate this new deriving strategy so tightly >with the existing deriving framework? I think it's at least worth >trying. The `deriving` code path is just different enough from the code >path for ordinary class instances where I think you'll encounter some >oddities if you try to implement the `th` deriving strategy out of >band. For example, you'll want to be able to dump `th`-derived code >that you generate using -ddump-deriv, which currently only happens in >the `deriving` code path. I suppose you could change things so that >-ddump-deriv does things in multiple places in the code, but I worry >that that may lead to an uncomfortable amount of code duplication. (Not >to mention that you'll have to be careful to actually emulate >everything that the `deriving` code path does, because if you forget >something, then that can lead to confusing bugs down the road.) >Of course, I won't claim that the current design of the `deriving` code >path is perfect by any means. If there are ways we could clean things >up that would make it easier to implement the `th` deriving strategy, >then we should consider doing that. >I'm not sure if I fully answered the spirit of your question, so feel >free to ask follow-up questions with specifics if I missed the mark. > >Best, > >Ryan > >On Wed, Jun 19, 2024 at 4:52 AM Sebastian Graf >wrote: >>Hi Ryan and GHC devs, >> >>I'm working on-and-off on a prototype that enables use of >>TemplateHaskell as a deriving strategy: >>https://gitlab.haskell.org/ghc/ghc/-/commit/82aea77ed908fe36bed829c9c4a01ea9b30a0181. >>My current working example is: >> >>``` >>{-# LANGUAGE TemplateHaskell #-} >>{-# LANGUAGE TypeFamilies #-} >> >>module T12457A where >> >>import GHC.Internal.TH.Lib >>import GHC.Internal.TH.Syntax >> >>class C a where >> type Assoc a >> m :: a -> Int >> n :: a -> Int >> >>instance DeriveTH C where >> deriveTH _p head = do >> let AppT (ConT t) (VarT a) = head >> x <- newName "x" >> x2 <- newName "x" >> addTopDecls =<< [d| >> $(varP x) = 12 >> $(varP x2) = 23 |] >> [d| >> instance C $(varT a) => C ($(conT t) $(varT a)) where >> type Assoc ($(conT t) $(varT a)) = Char >> m :: Eq a => a -> Int >> m _ = $(varE x) + 42 >> {-# INLINE m #-} >> n :: Show a => a -> Int >> n _ = $(varE x2) + 13 |] >> >>--- >> >>{-# LANGUAGE TemplateHaskell #-} >>{-# LANGUAGE ConstraintKinds #-} >>{-# LANGUAGE DerivingStrategies #-} >> >>module T12457 where >> >>import Language.Haskell.TH >>import GHC.Internal.TH.Lib >>import T12457A >> >>newtype T a = T [a] deriving th C >>``` >> >>I just managed to implement `GHC.Tc.Deriv.Infer.inferConstraints` for >>this mechanism (still hacky and broken in many ways) and am now stuck >>in `Deriv.genFamInst`. >>I realised I would need to replicate the first half of `tcClsInstDecl` >>to implement it. Before long, I will probably also need to replicate >>the other half to check method bindings. >>That leaves me wondering: Is it a good idea to integrate this new >>deriving strategy so tightly with the existing deriving framework? >>I would rather just call `tcClsInstDecl`, do a bit of sanity checking >>for specified constraints in standalone deriving declarations and call >>it a day. >> >>Given that you are the architect of our current deriving code, I hope >>you are the right person to ask for input. >> >>Thanks, >>Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed Jun 19 18:32:54 2024 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 19 Jun 2024 19:32:54 +0100 Subject: TTG and annotations In-Reply-To: References: Message-ID: Hi Simon The perennial problem. I was intending to tackle this before my talk at ZuriHac, but the last minute things for the 9.10.1 release chewed up all my time. I think it has got to a point now where I hope it can be explained meaningfully, and intend to tackle it, once I finish updating the ghc-exactprint consumers for GHC 9.10.1. Alan On Tue, 18 Jun 2024 at 16:43, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Hi Alan > > I know that you are continuing to work hard on annotations in the TTG > extension fields -- thank you. > > As you know, I'm very eager to get a big Note to explain how it all > works. At the moment I am completely lost, and I am reduced to > cargo-culting code by copy/pasting and hoping for the best. Plus we are > over-reliant on you, which isn't really fair on you. > > Several of us (including me and Rodrigo, and doubtless other ghc-devs, > cc'd) would be happy to review, edit, and improve -- but it is hard for us > to see the "big picture". > > Could you see your way to drafting something? It need not be that long > initially, but having *something* to ask questions about and improve would > be super helpful. > > I suggest drafting it in a Google doc so it was easy to edit, and for > others to contribute to, but ultimately it should be in the repo. > > Thanks! > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Jun 20 18:51:25 2024 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 20 Jun 2024 19:51:25 +0100 Subject: HsCmdArrForm Fixity Message-ID: We are currently wrapping up https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12842, which moves Fixity declarations into TTG extensions point, and into the haskell syntax, not GHC. But rnCmd for HsCommandArrForm in current master has rnCmd (HsCmdArrForm _ op _ (Just _) [arg1, arg2]) ... It matches on HsCmd GhcPs, which never introduce the `Just` form for fixity. The only place the `Just` form is introduced, is in mkOpFormRn, but this is only ever called from this specific equation. So both can be removed, without changing behaviour. The question is, this code was added for a reason at some point, what has broken in the meantime? Should this be fixed somehow instead of being removed? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Fri Jun 21 09:57:23 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 21 Jun 2024 10:57:23 +0100 Subject: HsCmdArrForm Fixity In-Reply-To: References: Message-ID: That looks strange. I would just blaze ahead and do what seems sensible. That (Just _) equation was introduced by Daniel Winorgrad-Cort in the commit below. You could try to see what that commit did, I suppose. (Twelve years ago.) Arrows are sadly un-loved (need a champion) so I think you'll just have to do your best. Simon *commit ba56d20d767f0425f6f7515fa9c78b186589b896* Author: Simon Peyton Jones Date: Wed Oct 3 11:16:22 2012 +0100 This big patch re-factors the way in which arrow-syntax is handled All the work was done by Dan Winograd-Cort. The main thing is that arrow comamnds now have their own data type HsCmd (defined in HsExpr). Previously it was punned with the HsExpr type, which was jolly confusing, and made it hard to do anything arrow-specific. To make this work, we now parameterise * MatchGroup * Match * GRHSs, GRHS * StmtLR and friends over the "body", that is the kind of thing they enclose. This "body" parameter can be instantiated to either LHsExpr or LHsCmd respectively. Everything else is really a knock-on effect; there should be no change (yet!) in behaviour. But it should be a sounder basis for fixing bugs. On Thu, 20 Jun 2024 at 19:51, Alan & Kim Zimmerman wrote: > We are currently wrapping up > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12842, which moves > Fixity declarations into TTG extensions point, and into the haskell syntax, > not GHC. > > But rnCmd for HsCommandArrForm in current master has > > rnCmd (HsCmdArrForm _ op _ (Just _) [arg1, arg2]) > ... > > It matches on HsCmd GhcPs, which never introduce the `Just` form for > fixity. > > The only place the `Just` form is introduced, is in mkOpFormRn, but this > is only ever called from this specific equation. So both can be removed, > without changing behaviour. > > The question is, this code was added for a reason at some point, what has > broken in the meantime? Should this be fixed somehow instead of being > removed? > > Alan > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Mon Jun 24 10:14:34 2024 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 24 Jun 2024 10:14:34 +0000 Subject: Deriving via TH (#12457) In-Reply-To: References: Message-ID: Hi Ryan and devs, I opened https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12941 with my progress, which seems to work for reasonable examples. No documentation yet and almost no test coverage, though. Cheers, Sebastian ------ Originalnachricht ------ Von "Sebastian Graf" An "Ryan Scott" Cc "GHC developers" Datum 19.06.2024 17:21:33 Betreff Re[2]: Deriving via TH (#12457) >Hi Ryan, > >Thank you for such a detailed reply! >What you wrote gave me confidence in just duplicating code from >`tcClsInstDecl`. >The code is a bit of mess now because the tyvars chosen for the >`deriving` instance head might not match with the tyvars used returned >in the splice, but I think we can sort this out during review once we >have a running prototype. > >Sebastian > >------ Originalnachricht ------ >Von "Ryan Scott" >An "Sebastian Graf" >Cc "GHC developers" >Datum 19.06.2024 15:07:47 >Betreff Re: Deriving via TH (#12457) > >>Hi Sebastian, >> >>This is exciting! I haven't taken a close look at the implementation, >>but here are my initial reactions: >>The implementation of `deriving` proceeds in a somewhat unusual way: >>you first typecheck the `deriving` clause and use the resulting Core >>types to figure out what the instance head should be. Then, you >>generate the method bindings for the instance as parsed code, then >>proceed to rename and typecheck the bindings. As such, `deriving` goes >>from typechecking -> renaming -> typechecking, which is somewhat >>odd... >>...and derived type family instances work in an even more odd way. >>Rather than generating parsed type family instance declarations (and >>then renaming/typechecking them), `deriving` directly generates Core >>axioms for the instances. As such, derived associated type family >>instances go through a rather different code path than derived method >>bindings. (There are technical reasons why this is the case, but I >>won't get into them here.) This asymmetry means that the existing >>`deriving` machinery has to do some odd things to make everything fit >>together. >>I think part of the difficulty you're encountering is that the `th` >>deriving strategy is attempting to produce associated type family >>instances from TH quotes (i.e., parsed code), rather than from >>typechecked code. Every other deriving strategy produces its >>associated type family instances from Core types, however, so they are >>able to generate instances without renaming or typechecking. You don't >>have that luxury. As such, I agree that you'll need to reuse other >>parts of the renamer and typechecker (e.g., the `tcClsInstDecl` >>function) in order to turn your TH-quoted type family instances into >>Core axioms. >>Is it a good idea to integrate this new deriving strategy so tightly >>with the existing deriving framework? I think it's at least worth >>trying. The `deriving` code path is just different enough from the >>code path for ordinary class instances where I think you'll encounter >>some oddities if you try to implement the `th` deriving strategy out >>of band. For example, you'll want to be able to dump `th`-derived code >>that you generate using -ddump-deriv, which currently only happens in >>the `deriving` code path. I suppose you could change things so that >>-ddump-deriv does things in multiple places in the code, but I worry >>that that may lead to an uncomfortable amount of code duplication. >>(Not to mention that you'll have to be careful to actually emulate >>everything that the `deriving` code path does, because if you forget >>something, then that can lead to confusing bugs down the road.) >>Of course, I won't claim that the current design of the `deriving` >>code path is perfect by any means. If there are ways we could clean >>things up that would make it easier to implement the `th` deriving >>strategy, then we should consider doing that. >>I'm not sure if I fully answered the spirit of your question, so feel >>free to ask follow-up questions with specifics if I missed the mark. >> >>Best, >> >>Ryan >> >>On Wed, Jun 19, 2024 at 4:52 AM Sebastian Graf >>wrote: >>>Hi Ryan and GHC devs, >>> >>>I'm working on-and-off on a prototype that enables use of >>>TemplateHaskell as a deriving strategy: >>>https://gitlab.haskell.org/ghc/ghc/-/commit/82aea77ed908fe36bed829c9c4a01ea9b30a0181. >>>My current working example is: >>> >>>``` >>>{-# LANGUAGE TemplateHaskell #-} >>>{-# LANGUAGE TypeFamilies #-} >>> >>>module T12457A where >>> >>>import GHC.Internal.TH.Lib >>>import GHC.Internal.TH.Syntax >>> >>>class C a where >>> type Assoc a >>> m :: a -> Int >>> n :: a -> Int >>> >>>instance DeriveTH C where >>> deriveTH _p head = do >>> let AppT (ConT t) (VarT a) = head >>> x <- newName "x" >>> x2 <- newName "x" >>> addTopDecls =<< [d| >>> $(varP x) = 12 >>> $(varP x2) = 23 |] >>> [d| >>> instance C $(varT a) => C ($(conT t) $(varT a)) where >>> type Assoc ($(conT t) $(varT a)) = Char >>> m :: Eq a => a -> Int >>> m _ = $(varE x) + 42 >>> {-# INLINE m #-} >>> n :: Show a => a -> Int >>> n _ = $(varE x2) + 13 |] >>> >>>--- >>> >>>{-# LANGUAGE TemplateHaskell #-} >>>{-# LANGUAGE ConstraintKinds #-} >>>{-# LANGUAGE DerivingStrategies #-} >>> >>>module T12457 where >>> >>>import Language.Haskell.TH >>>import GHC.Internal.TH.Lib >>>import T12457A >>> >>>newtype T a = T [a] deriving th C >>>``` >>> >>>I just managed to implement `GHC.Tc.Deriv.Infer.inferConstraints` for >>>this mechanism (still hacky and broken in many ways) and am now stuck >>>in `Deriv.genFamInst`. >>>I realised I would need to replicate the first half of >>>`tcClsInstDecl` to implement it. Before long, I will probably also >>>need to replicate the other half to check method bindings. >>>That leaves me wondering: Is it a good idea to integrate this new >>>deriving strategy so tightly with the existing deriving framework? >>>I would rather just call `tcClsInstDecl`, do a bit of sanity checking >>>for specified constraints in standalone deriving declarations and >>>call it a day. >>> >>>Given that you are the architect of our current deriving code, I hope >>>you are the right person to ask for input. >>> >>>Thanks, >>>Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: