From jaro.reinders at gmail.com Sat Dec 2 14:50:50 2023 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Sat, 2 Dec 2023 15:50:50 +0100 Subject: Annotating instances Message-ID: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Hi GHC devs, I'm working on a GHC plugin which implements a custom instance resolution mechanism: https://github.com/noughtmare/transitive-constraint-plugin Currently, I need to place instances in a specific order in a specific file to recognize them and use them in my plugin. I think my life would be a lot easier if I could put annotations on instances. I imagine a syntax like this: data MyInstanceTypes = Refl | Trans deriving Eq class f <= g where inj :: f x -> g x instance {-# ANN instance Refl #-} f <= f where inj = id instance {-# ANN instance Trans #-} forall f g h. (f <= g, g <= h) => f <= h where inj = inj @g @h . inj @f @g Using this information I should be able to find the right instances in a more reliable way. One more thing I was thinking about is to make it possible to remove these instances from the normal resolution algorithm and only allow them to be used by my plugin. Do you think this would be easy to implement and useful? Or are there other ways to achieve this? Cheers, Jaro From simon.peytonjones at gmail.com Mon Dec 4 09:00:40 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Dec 2023 09:00:40 +0000 Subject: Annotating instances In-Reply-To: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> References: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Message-ID: The whole ANN mechanism is, at root, a good idea. It is pretty generan, and allows annotations to be arbitrary expressions, provided they are in Typable and Data. And they are serialised across modules. In practice though, I'm not sure how widely used they are. I'm not sure why. I'd love to hear of counter-examples. Only top level binders can be annotated; but there is no reason in principle that you should not annotate instance declarations. I don't think it'd be too hard to implement. Simon On Sat, 2 Dec 2023 at 14:51, Jaro Reinders wrote: > Hi GHC devs, > > I'm working on a GHC plugin which implements a custom instance resolution > mechanism: > > https://github.com/noughtmare/transitive-constraint-plugin > > Currently, I need to place instances in a specific order in a specific > file to > recognize them and use them in my plugin. I think my life would be a lot > easier > if I could put annotations on instances. I imagine a syntax like this: > > data MyInstanceTypes = Refl | Trans deriving Eq > > class f <= g where > inj :: f x -> g x > > instance {-# ANN instance Refl #-} f <= f where > inj = id > > instance {-# ANN instance Trans #-} > forall f g h. (f <= g, g <= h) => f <= h > where > inj = inj @g @h . inj @f @g > > Using this information I should be able to find the right instances in a > more > reliable way. > > One more thing I was thinking about is to make it possible to remove these > instances from the normal resolution algorithm and only allow them to be > used > by my plugin. > > Do you think this would be easy to implement and useful? Or are there > other > ways to achieve this? > > Cheers, > > Jaro > _______________________________________________ > 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 moritz.angermann at gmail.com Mon Dec 4 09:05:24 2023 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Mon, 4 Dec 2023 17:05:24 +0800 Subject: Annotating instances In-Reply-To: References: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Message-ID: Any ANN annotation triggers the TH pipeline and makes them really painful to work with, in non-stage2 settings. Lots of Hlint annotations use ANN and then you have iserv be triggered for each module that has an ANN annotation. Luckily Hlint also support HLINT instead which removed the TH pipeline. That alone is enough for me personally to recommend against using ANN if there is an alternator option to anyone who asks me. On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > The whole ANN mechanism > is, > at root, a good idea. It is pretty generan, and allows annotations to be > arbitrary expressions, provided they are in Typable and Data. And they are > serialised across modules. > > In practice though, I'm not sure how widely used they are. I'm not sure > why. I'd love to hear of counter-examples. > > Only top level binders can be annotated; but there is no reason in > principle that you should not annotate instance declarations. I don't > think it'd be too hard to implement. > > Simon > > On Sat, 2 Dec 2023 at 14:51, Jaro Reinders > wrote: > >> Hi GHC devs, >> >> I'm working on a GHC plugin which implements a custom instance resolution >> mechanism: >> >> https://github.com/noughtmare/transitive-constraint-plugin >> >> Currently, I need to place instances in a specific order in a specific >> file to >> recognize them and use them in my plugin. I think my life would be a lot >> easier >> if I could put annotations on instances. I imagine a syntax like this: >> >> data MyInstanceTypes = Refl | Trans deriving Eq >> >> class f <= g where >> inj :: f x -> g x >> >> instance {-# ANN instance Refl #-} f <= f where >> inj = id >> >> instance {-# ANN instance Trans #-} >> forall f g h. (f <= g, g <= h) => f <= h >> where >> inj = inj @g @h . inj @f @g >> >> Using this information I should be able to find the right instances in a >> more >> reliable way. >> >> One more thing I was thinking about is to make it possible to remove >> these >> instances from the normal resolution algorithm and only allow them to be >> used >> by my plugin. >> >> Do you think this would be easy to implement and useful? Or are there >> other >> ways to achieve this? >> >> Cheers, >> >> Jaro >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > 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 simon.peytonjones at gmail.com Mon Dec 4 11:45:05 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Dec 2023 11:45:05 +0000 Subject: Annotating instances In-Reply-To: References: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Message-ID: > > Luckily Hlint also support HLINT instead which removed the TH pipeline. > Where is this described/documented? All I can see here is > For {-# HLINT #-} pragmas GHC may give a warning about an unrecognised > pragma, which can be suppressed with -Wno-unrecognised-pragmas. > which mentions HLINT pragmas but says nothing about what they do. Simon On Mon, 4 Dec 2023 at 09:05, Moritz Angermann wrote: > Any ANN annotation triggers the TH pipeline and makes them really painful > to work with, in non-stage2 settings. Lots of Hlint annotations use ANN and > then you have iserv be triggered for each module that has an ANN annotation. > > Luckily Hlint also support HLINT instead which removed the TH pipeline. > > That alone is enough for me personally to recommend against using ANN if > there is an alternator option to anyone who asks me. > > On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> The whole ANN mechanism >> is, >> at root, a good idea. It is pretty generan, and allows annotations to be >> arbitrary expressions, provided they are in Typable and Data. And they are >> serialised across modules. >> >> In practice though, I'm not sure how widely used they are. I'm not sure >> why. I'd love to hear of counter-examples. >> >> Only top level binders can be annotated; but there is no reason in >> principle that you should not annotate instance declarations. I don't >> think it'd be too hard to implement. >> >> Simon >> >> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders >> wrote: >> >>> Hi GHC devs, >>> >>> I'm working on a GHC plugin which implements a custom instance >>> resolution >>> mechanism: >>> >>> https://github.com/noughtmare/transitive-constraint-plugin >>> >>> Currently, I need to place instances in a specific order in a specific >>> file to >>> recognize them and use them in my plugin. I think my life would be a lot >>> easier >>> if I could put annotations on instances. I imagine a syntax like this: >>> >>> data MyInstanceTypes = Refl | Trans deriving Eq >>> >>> class f <= g where >>> inj :: f x -> g x >>> >>> instance {-# ANN instance Refl #-} f <= f where >>> inj = id >>> >>> instance {-# ANN instance Trans #-} >>> forall f g h. (f <= g, g <= h) => f <= h >>> where >>> inj = inj @g @h . inj @f @g >>> >>> Using this information I should be able to find the right instances in a >>> more >>> reliable way. >>> >>> One more thing I was thinking about is to make it possible to remove >>> these >>> instances from the normal resolution algorithm and only allow them to be >>> used >>> by my plugin. >>> >>> Do you think this would be easy to implement and useful? Or are there >>> other >>> ways to achieve this? >>> >>> Cheers, >>> >>> Jaro >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> 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 moritz.angermann at gmail.com Mon Dec 4 11:58:10 2023 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Mon, 4 Dec 2023 19:58:10 +0800 Subject: Annotating instances In-Reply-To: References: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Message-ID: I don’t think they do anything specific. They just function as a marker to Hlint to find when parsing the source files. Here is one of the original issues we had: https://github.com/ndmitchell/hlint/issues/1251 Simply by not being ANN, it doesn’t trigger the Templar Haskell machinery and thus does not cause compilation slowdowns or iserv needs (e.g. render the module impossible to cross compiler for stage1 cross compilers with not TH support). On Mon, 4 Dec 2023 at 7:45 PM, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Luckily Hlint also support HLINT instead which removed the TH pipeline. >> > > Where is this described/documented? All I can see here > is > >> For {-# HLINT #-} pragmas GHC may give a warning about an unrecognised >> pragma, which can be suppressed with -Wno-unrecognised-pragmas. >> > which mentions HLINT pragmas but says nothing about what they do. > > Simon > > On Mon, 4 Dec 2023 at 09:05, Moritz Angermann > wrote: > >> Any ANN annotation triggers the TH pipeline and makes them really painful >> to work with, in non-stage2 settings. Lots of Hlint annotations use ANN and >> then you have iserv be triggered for each module that has an ANN annotation. >> >> Luckily Hlint also support HLINT instead which removed the TH pipeline. >> >> That alone is enough for me personally to recommend against using ANN if >> there is an alternator option to anyone who asks me. >> >> On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> The whole ANN mechanism >>> is, >>> at root, a good idea. It is pretty generan, and allows annotations to be >>> arbitrary expressions, provided they are in Typable and Data. And they are >>> serialised across modules. >>> >>> In practice though, I'm not sure how widely used they are. I'm not sure >>> why. I'd love to hear of counter-examples. >>> >>> Only top level binders can be annotated; but there is no reason in >>> principle that you should not annotate instance declarations. I don't >>> think it'd be too hard to implement. >>> >>> Simon >>> >>> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders >>> wrote: >>> >>>> Hi GHC devs, >>>> >>>> I'm working on a GHC plugin which implements a custom instance >>>> resolution >>>> mechanism: >>>> >>>> https://github.com/noughtmare/transitive-constraint-plugin >>>> >>>> Currently, I need to place instances in a specific order in a specific >>>> file to >>>> recognize them and use them in my plugin. I think my life would be a >>>> lot easier >>>> if I could put annotations on instances. I imagine a syntax like this: >>>> >>>> data MyInstanceTypes = Refl | Trans deriving Eq >>>> >>>> class f <= g where >>>> inj :: f x -> g x >>>> >>>> instance {-# ANN instance Refl #-} f <= f where >>>> inj = id >>>> >>>> instance {-# ANN instance Trans #-} >>>> forall f g h. (f <= g, g <= h) => f <= h >>>> where >>>> inj = inj @g @h . inj @f @g >>>> >>>> Using this information I should be able to find the right instances in >>>> a more >>>> reliable way. >>>> >>>> One more thing I was thinking about is to make it possible to remove >>>> these >>>> instances from the normal resolution algorithm and only allow them to >>>> be used >>>> by my plugin. >>>> >>>> Do you think this would be easy to implement and useful? Or are there >>>> other >>>> ways to achieve this? >>>> >>>> Cheers, >>>> >>>> Jaro >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> _______________________________________________ >>> 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 simon.peytonjones at gmail.com Mon Dec 4 12:07:38 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Dec 2023 12:07:38 +0000 Subject: Annotating instances In-Reply-To: References: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Message-ID: > I don’t think they do anything specific. Now I am truly baffled! If they don't do anything, why would they be a module at all! Surely they do something? Simon On Mon, 4 Dec 2023 at 11:58, Moritz Angermann wrote: > I don’t think they do anything specific. They just function as a marker to > Hlint to find when parsing the source files. Here is one of the original > issues we had: > https://github.com/ndmitchell/hlint/issues/1251 > > Simply by not being ANN, it doesn’t trigger the Templar Haskell machinery > and thus does not cause compilation slowdowns or iserv needs (e.g. render > the module impossible to cross compiler for stage1 cross compilers with not > TH support). > > On Mon, 4 Dec 2023 at 7:45 PM, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> Luckily Hlint also support HLINT instead which removed the TH pipeline. >>> >> >> Where is this described/documented? All I can see here >> is >> >>> For {-# HLINT #-} pragmas GHC may give a warning about an unrecognised >>> pragma, which can be suppressed with -Wno-unrecognised-pragmas. >>> >> which mentions HLINT pragmas but says nothing about what they do. >> >> Simon >> >> On Mon, 4 Dec 2023 at 09:05, Moritz Angermann >> wrote: >> >>> Any ANN annotation triggers the TH pipeline and makes them really >>> painful to work with, in non-stage2 settings. Lots of Hlint annotations use >>> ANN and then you have iserv be triggered for each module that has an ANN >>> annotation. >>> >>> Luckily Hlint also support HLINT instead which removed the TH pipeline. >>> >>> That alone is enough for me personally to recommend against using ANN if >>> there is an alternator option to anyone who asks me. >>> >>> On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones < >>> simon.peytonjones at gmail.com> wrote: >>> >>>> The whole ANN mechanism >>>> is, >>>> at root, a good idea. It is pretty generan, and allows annotations to be >>>> arbitrary expressions, provided they are in Typable and Data. And they are >>>> serialised across modules. >>>> >>>> In practice though, I'm not sure how widely used they are. I'm not sure >>>> why. I'd love to hear of counter-examples. >>>> >>>> Only top level binders can be annotated; but there is no reason in >>>> principle that you should not annotate instance declarations. I don't >>>> think it'd be too hard to implement. >>>> >>>> Simon >>>> >>>> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders >>>> wrote: >>>> >>>>> Hi GHC devs, >>>>> >>>>> I'm working on a GHC plugin which implements a custom instance >>>>> resolution >>>>> mechanism: >>>>> >>>>> https://github.com/noughtmare/transitive-constraint-plugin >>>>> >>>>> Currently, I need to place instances in a specific order in a specific >>>>> file to >>>>> recognize them and use them in my plugin. I think my life would be a >>>>> lot easier >>>>> if I could put annotations on instances. I imagine a syntax like this: >>>>> >>>>> data MyInstanceTypes = Refl | Trans deriving Eq >>>>> >>>>> class f <= g where >>>>> inj :: f x -> g x >>>>> >>>>> instance {-# ANN instance Refl #-} f <= f where >>>>> inj = id >>>>> >>>>> instance {-# ANN instance Trans #-} >>>>> forall f g h. (f <= g, g <= h) => f <= h >>>>> where >>>>> inj = inj @g @h . inj @f @g >>>>> >>>>> Using this information I should be able to find the right instances in >>>>> a more >>>>> reliable way. >>>>> >>>>> One more thing I was thinking about is to make it possible to remove >>>>> these >>>>> instances from the normal resolution algorithm and only allow them to >>>>> be used >>>>> by my plugin. >>>>> >>>>> Do you think this would be easy to implement and useful? Or are there >>>>> other >>>>> ways to achieve this? >>>>> >>>>> Cheers, >>>>> >>>>> Jaro >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>> _______________________________________________ >>>> 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 moritz.angermann at gmail.com Mon Dec 4 12:15:04 2023 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Mon, 4 Dec 2023 20:15:04 +0800 Subject: Annotating instances In-Reply-To: References: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Message-ID: I see. That’s where the confusion comes from. Hlint uses them to allow ignoring specific Hlint warnings: {-# ANN module "HLint: ignore Use string literal" #-} {- HLINT ignore "Use string literal" -} and similar. One could maybe argue they should have never been ANN pragmas to begin with. Examples taken from this SO question: https://stackoverflow.com/questions/19237695/haskell-how-to-tell-hlint-not-to-warning-use-string-literal On Mon, 4 Dec 2023 at 8:07 PM, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > > I don’t think they do anything specific. > > Now I am truly baffled! If they don't do anything, why would they be a > module at all! Surely they do something? > > Simon > > On Mon, 4 Dec 2023 at 11:58, Moritz Angermann > wrote: > >> I don’t think they do anything specific. They just function as a marker >> to Hlint to find when parsing the source files. Here is one of the original >> issues we had: >> https://github.com/ndmitchell/hlint/issues/1251 >> >> Simply by not being ANN, it doesn’t trigger the Templar Haskell machinery >> and thus does not cause compilation slowdowns or iserv needs (e.g. render >> the module impossible to cross compiler for stage1 cross compilers with not >> TH support). >> >> On Mon, 4 Dec 2023 at 7:45 PM, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> Luckily Hlint also support HLINT instead which removed the TH pipeline. >>>> >>> >>> Where is this described/documented? All I can see here >>> is >>> >>>> For {-# HLINT #-} pragmas GHC may give a warning about an unrecognised >>>> pragma, which can be suppressed with -Wno-unrecognised-pragmas. >>>> >>> which mentions HLINT pragmas but says nothing about what they do. >>> >>> Simon >>> >>> On Mon, 4 Dec 2023 at 09:05, Moritz Angermann < >>> moritz.angermann at gmail.com> wrote: >>> >>>> Any ANN annotation triggers the TH pipeline and makes them really >>>> painful to work with, in non-stage2 settings. Lots of Hlint annotations use >>>> ANN and then you have iserv be triggered for each module that has an ANN >>>> annotation. >>>> >>>> Luckily Hlint also support HLINT instead which removed the TH pipeline. >>>> >>>> That alone is enough for me personally to recommend against using ANN >>>> if there is an alternator option to anyone who asks me. >>>> >>>> On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones < >>>> simon.peytonjones at gmail.com> wrote: >>>> >>>>> The whole ANN mechanism >>>>> is, >>>>> at root, a good idea. It is pretty generan, and allows annotations to be >>>>> arbitrary expressions, provided they are in Typable and Data. And they are >>>>> serialised across modules. >>>>> >>>>> In practice though, I'm not sure how widely used they are. I'm not >>>>> sure why. I'd love to hear of counter-examples. >>>>> >>>>> Only top level binders can be annotated; but there is no reason in >>>>> principle that you should not annotate instance declarations. I don't >>>>> think it'd be too hard to implement. >>>>> >>>>> Simon >>>>> >>>>> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders >>>>> wrote: >>>>> >>>>>> Hi GHC devs, >>>>>> >>>>>> I'm working on a GHC plugin which implements a custom instance >>>>>> resolution >>>>>> mechanism: >>>>>> >>>>>> https://github.com/noughtmare/transitive-constraint-plugin >>>>>> >>>>>> Currently, I need to place instances in a specific order in a >>>>>> specific file to >>>>>> recognize them and use them in my plugin. I think my life would be a >>>>>> lot easier >>>>>> if I could put annotations on instances. I imagine a syntax like this: >>>>>> >>>>>> data MyInstanceTypes = Refl | Trans deriving Eq >>>>>> >>>>>> class f <= g where >>>>>> inj :: f x -> g x >>>>>> >>>>>> instance {-# ANN instance Refl #-} f <= f where >>>>>> inj = id >>>>>> >>>>>> instance {-# ANN instance Trans #-} >>>>>> forall f g h. (f <= g, g <= h) => f <= h >>>>>> where >>>>>> inj = inj @g @h . inj @f @g >>>>>> >>>>>> Using this information I should be able to find the right instances >>>>>> in a more >>>>>> reliable way. >>>>>> >>>>>> One more thing I was thinking about is to make it possible to remove >>>>>> these >>>>>> instances from the normal resolution algorithm and only allow them to >>>>>> be used >>>>>> by my plugin. >>>>>> >>>>>> Do you think this would be easy to implement and useful? Or are there >>>>>> other >>>>>> ways to achieve this? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jaro >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>> >>>>> _______________________________________________ >>>>> 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 simon.peytonjones at gmail.com Mon Dec 4 12:21:37 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Dec 2023 12:21:37 +0000 Subject: Annotating instances In-Reply-To: References: <793a7f60-7900-408b-8fe2-3a8f06c00291@gmail.com> Message-ID: Ah, so returning to my original question: Where is this described/documented? All I can see here > is... > E.g. is there a HLint user guide? I'm interested in what the annotations can and cannot be. E.g. perhaps ANN could shortcircuit the TH stuff in some common cases? Simon On Mon, 4 Dec 2023 at 12:15, Moritz Angermann wrote: > I see. That’s where the confusion comes from. Hlint uses them to allow > ignoring specific Hlint warnings: > > {-# ANN module "HLint: ignore Use string literal" #-} > > {- HLINT ignore "Use string literal" -} > > and similar. One could maybe argue they should have never been ANN pragmas > to begin with. > > Examples taken from this SO question: > > https://stackoverflow.com/questions/19237695/haskell-how-to-tell-hlint-not-to-warning-use-string-literal > > On Mon, 4 Dec 2023 at 8:07 PM, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> > I don’t think they do anything specific. >> >> Now I am truly baffled! If they don't do anything, why would they be a >> module at all! Surely they do something? >> >> Simon >> >> On Mon, 4 Dec 2023 at 11:58, Moritz Angermann >> wrote: >> >>> I don’t think they do anything specific. They just function as a marker >>> to Hlint to find when parsing the source files. Here is one of the original >>> issues we had: >>> https://github.com/ndmitchell/hlint/issues/1251 >>> >>> Simply by not being ANN, it doesn’t trigger the Templar Haskell >>> machinery and thus does not cause compilation slowdowns or iserv needs >>> (e.g. render the module impossible to cross compiler for stage1 cross >>> compilers with not TH support). >>> >>> On Mon, 4 Dec 2023 at 7:45 PM, Simon Peyton Jones < >>> simon.peytonjones at gmail.com> wrote: >>> >>>> Luckily Hlint also support HLINT instead which removed the TH pipeline. >>>>> >>>> >>>> Where is this described/documented? All I can see here >>>> is >>>> >>>>> For {-# HLINT #-} pragmas GHC may give a warning about an >>>>> unrecognised pragma, which can be suppressed with >>>>> -Wno-unrecognised-pragmas. >>>>> >>>> which mentions HLINT pragmas but says nothing about what they do. >>>> >>>> Simon >>>> >>>> On Mon, 4 Dec 2023 at 09:05, Moritz Angermann < >>>> moritz.angermann at gmail.com> wrote: >>>> >>>>> Any ANN annotation triggers the TH pipeline and makes them really >>>>> painful to work with, in non-stage2 settings. Lots of Hlint annotations use >>>>> ANN and then you have iserv be triggered for each module that has an ANN >>>>> annotation. >>>>> >>>>> Luckily Hlint also support HLINT instead which removed the TH pipeline. >>>>> >>>>> That alone is enough for me personally to recommend against using ANN >>>>> if there is an alternator option to anyone who asks me. >>>>> >>>>> On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones < >>>>> simon.peytonjones at gmail.com> wrote: >>>>> >>>>>> The whole ANN mechanism >>>>>> is, >>>>>> at root, a good idea. It is pretty generan, and allows annotations to be >>>>>> arbitrary expressions, provided they are in Typable and Data. And they are >>>>>> serialised across modules. >>>>>> >>>>>> In practice though, I'm not sure how widely used they are. I'm not >>>>>> sure why. I'd love to hear of counter-examples. >>>>>> >>>>>> Only top level binders can be annotated; but there is no reason in >>>>>> principle that you should not annotate instance declarations. I don't >>>>>> think it'd be too hard to implement. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders >>>>>> wrote: >>>>>> >>>>>>> Hi GHC devs, >>>>>>> >>>>>>> I'm working on a GHC plugin which implements a custom instance >>>>>>> resolution >>>>>>> mechanism: >>>>>>> >>>>>>> https://github.com/noughtmare/transitive-constraint-plugin >>>>>>> >>>>>>> Currently, I need to place instances in a specific order in a >>>>>>> specific file to >>>>>>> recognize them and use them in my plugin. I think my life would be a >>>>>>> lot easier >>>>>>> if I could put annotations on instances. I imagine a syntax like >>>>>>> this: >>>>>>> >>>>>>> data MyInstanceTypes = Refl | Trans deriving Eq >>>>>>> >>>>>>> class f <= g where >>>>>>> inj :: f x -> g x >>>>>>> >>>>>>> instance {-# ANN instance Refl #-} f <= f where >>>>>>> inj = id >>>>>>> >>>>>>> instance {-# ANN instance Trans #-} >>>>>>> forall f g h. (f <= g, g <= h) => f <= h >>>>>>> where >>>>>>> inj = inj @g @h . inj @f @g >>>>>>> >>>>>>> Using this information I should be able to find the right instances >>>>>>> in a more >>>>>>> reliable way. >>>>>>> >>>>>>> One more thing I was thinking about is to make it possible to remove >>>>>>> these >>>>>>> instances from the normal resolution algorithm and only allow them >>>>>>> to be used >>>>>>> by my plugin. >>>>>>> >>>>>>> Do you think this would be easy to implement and useful? Or are >>>>>>> there other >>>>>>> ways to achieve this? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Jaro >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 alan.zimm at gmail.com Mon Dec 4 20:54:51 2023 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 4 Dec 2023 20:54:51 +0000 Subject: "Merge-buddy" response Message-ID: Hi all If you recall I asked a while back for people to help me get my exact print annotation re-work stack merged. I had a number of people step up to offer their help (Brandon Allbery, Zubin Duggal, Ben Gamari and Alexandre Baldé). Of these, Brandon Allbery really stepped up to the plate. We got into a daily rhythm and have now landed 37 Merge Requests, completing my initial rework. Thank you very much. There has been further discussion of next steps at https://gitlab.haskell.org/ghc/ghc/-/issues/23447, and I will be starting on the further simplification we have discussed there. Thanks again all. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Dec 7 09:39:10 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 7 Dec 2023 10:39:10 +0100 Subject: Build GHC in GHC2021 Message-ID: Dear GHC devs, Year 2024 is upon us. GHC2021 was released 2 years ago, in GHC 9.2. I think it's time for the base language for GHC to be GHC2021. What do we think? PS: I don't actually know where the base language for GHC is specified. I couldn't find it with a cursory search PPS: if someone makes an MR, bonus points for clearing up hundreds of lines of now-unnecessary extension on top of files. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Thu Dec 7 12:53:02 2023 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 7 Dec 2023 12:53:02 +0000 Subject: Build GHC in GHC2021 In-Reply-To: References: Message-ID: <010f018c4456b547-5f72310e-edc5-4854-818c-9b7d774253ca-000000@us-east-2.amazonses.com> I think this is an excellent idea! So excellent, that we've already done it. :) When I try to compile with GHC 9.6.2 (what I have lying around), GHC2021 is in effect. Is there something different you were thinking of? Thanks, Richard > On Dec 7, 2023, at 4:39 AM, Arnaud Spiwack wrote: > > Dear GHC devs, > > Year 2024 is upon us. GHC2021 was released 2 years ago, in GHC 9.2. I think it's time for the base language for GHC to be GHC2021. > > What do we think? > > PS: I don't actually know where the base language for GHC is specified. I couldn't find it with a cursory search > PPS: if someone makes an MR, bonus points for clearing up hundreds of lines of now-unnecessary extension on top of files. > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io . > _______________________________________________ > 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 tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Thu Dec 7 13:01:09 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 7 Dec 2023 13:01:09 +0000 Subject: Build GHC in GHC2021 In-Reply-To: <010f018c4456b547-5f72310e-edc5-4854-818c-9b7d774253ca-000000@us-east-2.amazonses.com> References: <010f018c4456b547-5f72310e-edc5-4854-818c-9b7d774253ca-000000@us-east-2.amazonses.com> Message-ID: On Thu, Dec 07, 2023 at 12:53:02PM +0000, Richard Eisenberg wrote: > I think this is an excellent idea! So excellent, that we've already done it. :) > > When I try to compile with GHC 9.6.2 (what I have lying around), GHC2021 is in effect. > > Is there something different you were thinking of? I think Arnaud meant that compilations of GHC's codebase itself should use the GHC2021 setting. From arnaud.spiwack at tweag.io Thu Dec 7 13:29:05 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 7 Dec 2023 14:29:05 +0100 Subject: Build GHC in GHC2021 In-Reply-To: References: <010f018c4456b547-5f72310e-edc5-4854-818c-9b7d774253ca-000000@us-east-2.amazonses.com> Message-ID: Indeed. I didn't realise the ambiguity in my wording. I'd like for GHC to be built, with Hadrian, using GHC2021 as the base language. On Thu, 7 Dec 2023 at 14:01, Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > On Thu, Dec 07, 2023 at 12:53:02PM +0000, Richard Eisenberg wrote: > > I think this is an excellent idea! So excellent, that we've already done > it. :) > > > > When I try to compile with GHC 9.6.2 (what I have lying around), GHC2021 > is in effect. > > > > Is there something different you were thinking of? > > I think Arnaud meant that compilations of GHC's codebase itself should > use the GHC2021 setting. > _______________________________________________ > 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 klebinger.andreas at gmx.at Fri Dec 8 11:33:27 2023 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Fri, 8 Dec 2023 12:33:27 +0100 Subject: Build GHC in GHC2021 In-Reply-To: References: <010f018c4456b547-5f72310e-edc5-4854-818c-9b7d774253ca-000000@us-east-2.amazonses.com> Message-ID: <181d2ee4-8580-4ac8-89f6-86552ad26932@gmx.at> On a whim tried enabling it by default but it failed first because GeneralizedNewtypeDeriving is incompatible with safe haskell and once I disabled GeneralizedNewtypeDeriving it failed with some error about missmatched kinds. I would welcome a patch doing this, but it's not a priority. Especially since it doesn't seem to be as simple as changing the base language and removing some pragmas. Am 07/12/2023 um 14:29 schrieb Arnaud Spiwack: > Indeed. I didn't realise the ambiguity in my wording. > > I'd like for GHC to be built, with Hadrian, using GHC2021 as the base > language. > > > On Thu, 7 Dec 2023 at 14:01, Tom Ellis > wrote: > > On Thu, Dec 07, 2023 at 12:53:02PM +0000, Richard Eisenberg wrote: > > I think this is an excellent idea! So excellent, that we've > already done it. :) > > > > When I try to compile with GHC 9.6.2 (what I have lying around), > GHC2021 is in effect. > > > > Is there something different you were thinking of? > > I think Arnaud meant that compilations of GHC's codebase itself should > use the GHC2021 setting. > _______________________________________________ > 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. > > _______________________________________________ > 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 oleg.grenrus at iki.fi Fri Dec 8 17:35:55 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 8 Dec 2023 19:35:55 +0200 Subject: Build GHC in GHC2021 In-Reply-To: <181d2ee4-8580-4ac8-89f6-86552ad26932@gmx.at> References: <010f018c4456b547-5f72310e-edc5-4854-818c-9b7d774253ca-000000@us-east-2.amazonses.com> <181d2ee4-8580-4ac8-89f6-86552ad26932@gmx.at> Message-ID: I think Arnaud was talkin about ghc, i.e. compiler/, not about everything (incl libraries/base e.g.). I tried, the PoC is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11743 I needed to do `NoPolyKinds` in few modules (could give kind signature too, but NoPolyKinds were quicker). Especially that hits hs-boot files. By doing `default-language: GHC2021`, and going through modules with BangPatterns (and removing that, and other GHC2021 extensions), the diff stats are nice: 91 files changed, 24 insertions(+), 272 deletions(-) - Oleg On 8.12.2023 13.33, Andreas Klebinger via ghc-devs wrote: > > On a whim tried enabling it by default but it failed first because > GeneralizedNewtypeDeriving is incompatible with safe haskell > and once I disabled GeneralizedNewtypeDeriving it failed with some > error about missmatched kinds. > > I would welcome a patch doing this, but it's not a priority. > Especially since it doesn't seem to be as simple as changing > the base language and removing some pragmas. > > Am 07/12/2023 um 14:29 schrieb Arnaud Spiwack: >> Indeed. I didn't realise the ambiguity in my wording. >> >> I'd like for GHC to be built, with Hadrian, using GHC2021 as the base >> language. >> >> >> On Thu, 7 Dec 2023 at 14:01, Tom Ellis >> wrote: >> >> On Thu, Dec 07, 2023 at 12:53:02PM +0000, Richard Eisenberg wrote: >> > I think this is an excellent idea! So excellent, that we've >> already done it. :) >> > >> > When I try to compile with GHC 9.6.2 (what I have lying >> around), GHC2021 is in effect. >> > >> > Is there something different you were thinking of? >> >> I think Arnaud meant that compilations of GHC's codebase itself >> should >> use the GHC2021 setting. >> _______________________________________________ >> 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. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > 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 arnaud.spiwack at tweag.io Mon Dec 11 08:38:54 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 11 Dec 2023 09:38:54 +0100 Subject: Build GHC in GHC2021 In-Reply-To: References: <010f018c4456b547-5f72310e-edc5-4854-818c-9b7d774253ca-000000@us-east-2.amazonses.com> <181d2ee4-8580-4ac8-89f6-86552ad26932@gmx.at> Message-ID: Thanks Oleg. I quite like what I'm seeing there! On Fri, 8 Dec 2023 at 18:36, Oleg Grenrus wrote: > I think Arnaud was talkin about ghc, i.e. compiler/, not about everything > (incl libraries/base e.g.). > > I tried, the PoC is at > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11743 > > I needed to do `NoPolyKinds` in few modules (could give kind signature > too, but NoPolyKinds were quicker). > Especially that hits hs-boot files. > > By doing `default-language: GHC2021`, and going through modules with > BangPatterns (and removing that, and other GHC2021 extensions), the diff > stats are nice: 91 files changed, 24 insertions(+), 272 deletions(-) > > - Oleg > On 8.12.2023 13.33, Andreas Klebinger via ghc-devs wrote: > > On a whim tried enabling it by default but it failed first because > GeneralizedNewtypeDeriving is incompatible with safe haskell > and once I disabled GeneralizedNewtypeDeriving it failed with some error > about missmatched kinds. > > I would welcome a patch doing this, but it's not a priority. Especially > since it doesn't seem to be as simple as changing > the base language and removing some pragmas. > Am 07/12/2023 um 14:29 schrieb Arnaud Spiwack: > > Indeed. I didn't realise the ambiguity in my wording. > > I'd like for GHC to be built, with Hadrian, using GHC2021 as the base > language. > > > On Thu, 7 Dec 2023 at 14:01, Tom Ellis < > tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > >> On Thu, Dec 07, 2023 at 12:53:02PM +0000, Richard Eisenberg wrote: >> > I think this is an excellent idea! So excellent, that we've already >> done it. :) >> > >> > When I try to compile with GHC 9.6.2 (what I have lying around), >> GHC2021 is in effect. >> > >> > Is there something different you were thinking of? >> >> I think Arnaud meant that compilations of GHC's codebase itself should >> use the GHC2021 setting. >> _______________________________________________ >> 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. > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > 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 tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Dec 12 08:50:19 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 12 Dec 2023 08:50:19 +0000 Subject: How is account sign-up supposed to work? Message-ID: Hello GHC devs, It is hard for new users to understand how to get their new Gitlab accounts approved by an administrator. See, for example, these messages, both in the last ten days: * https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-unicode-characters-like-chinese/8263/ * https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_reporting_ghcdebug_issues/ The Wiki doesn't seem to provide any guidance in the "Contributing" or "Newcomers" sections. Nor does ghc.dev. Perhaps that's understandable; GHC is not the Gitlab instance. * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc * https://ghc.dev/ So how is a new user supposed to know how to get their accounts approved? It would be nice to make the process super clear. This is a longstanding issue. Tom From andreyborzenkov2002 at gmail.com Tue Dec 12 09:01:42 2023 From: andreyborzenkov2002 at gmail.com (Andrei Borzenkov) Date: Tue, 12 Dec 2023 13:01:42 +0400 Subject: How is account sign-up supposed to work? In-Reply-To: References: Message-ID: Hello Tom, I think that this may be highlighted in the "newcomers" section, as you proposed, but "report a bug" wiki page already contains information about that you should ask for the account approval: * https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug Andrei 12.12.2023 12:50, Tom Ellis wrote: > Hello GHC devs, > > It is hard for new users to understand how to get their new Gitlab > accounts approved by an administrator. See, for example, these > messages, both in the last ten days: > > * https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-unicode-characters-like-chinese/8263/ > > * https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_reporting_ghcdebug_issues/ > > The Wiki doesn't seem to provide any guidance in the "Contributing" or > "Newcomers" sections. Nor does ghc.dev. Perhaps that's > understandable; GHC is not the Gitlab instance. > > * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing > > * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc > > * https://ghc.dev/ > > So how is a new user supposed to know how to get their accounts > approved? It would be nice to make the process super clear. This is > a longstanding issue. > > Tom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Dec 12 09:39:17 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 12 Dec 2023 09:39:17 +0000 Subject: How is account sign-up supposed to work? In-Reply-To: References: Message-ID: Ah, that's good to see! I copied the relevant information to the Newcomers section too: https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc On Tue, Dec 12, 2023 at 01:01:42PM +0400, Andrei Borzenkov wrote: > I think that this may be highlighted in the "newcomers" section, as you > proposed, but > "report a bug" wiki page already contains information about that you should > ask for the account approval: > > * https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug > > 12.12.2023 12:50, Tom Ellis wrote: > > Hello GHC devs, > > > > It is hard for new users to understand how to get their new Gitlab > > accounts approved by an administrator. See, for example, these > > messages, both in the last ten days: > > > > * https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-unicode-characters-like-chinese/8263/ > > > > * https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_reporting_ghcdebug_issues/ > > > > The Wiki doesn't seem to provide any guidance in the "Contributing" or > > "Newcomers" sections. Nor does ghc.dev. Perhaps that's > > understandable; GHC is not the Gitlab instance. > > > > * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing > > > > * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc > > > > * https://ghc.dev/ From bryan at haskell.foundation Tue Dec 12 10:01:58 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Tue, 12 Dec 2023 12:01:58 +0200 Subject: How is account sign-up supposed to work? In-Reply-To: References: Message-ID: Thanks for improving this! I've fleshed out the section about Matrix on the "mailing lists and irc" page. I won't change the title for fear it would break a bunch of links... On Tue, 12 Dec 2023 at 11:39, Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > Ah, that's good to see! I copied the relevant information to the > Newcomers section too: > > https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc > > On Tue, Dec 12, 2023 at 01:01:42PM +0400, Andrei Borzenkov wrote: > > I think that this may be highlighted in the "newcomers" section, as you > > proposed, but > > "report a bug" wiki page already contains information about that you > should > > ask for the account approval: > > > > * https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug > > > > 12.12.2023 12:50, Tom Ellis wrote: > > > Hello GHC devs, > > > > > > It is hard for new users to understand how to get their new Gitlab > > > accounts approved by an administrator. See, for example, these > > > messages, both in the last ten days: > > > > > > * > https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-unicode-characters-like-chinese/8263/ > > > > > > * > https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_reporting_ghcdebug_issues/ > > > > > > The Wiki doesn't seem to provide any guidance in the "Contributing" or > > > "Newcomers" sections. Nor does ghc.dev. Perhaps that's > > > understandable; GHC is not the Gitlab instance. > > > > > > * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing > > > > > > * > https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc > > > > > > * https://ghc.dev/ > _______________________________________________ > 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 dashiellwill at 163.com Sat Dec 16 09:15:31 2023 From: dashiellwill at 163.com (DashiellWill) Date: Sat, 16 Dec 2023 17:15:31 +0800 (CST) Subject: STG register mapping Message-ID: <77ac4cba.f38.18c71e8ce39.Coremail.dashiellwill@163.com> Hi all, I'm newbie at GHC, trying to read the source code and understand the design of GHC. Now I'm learning about the Haskell Execution Model, but now I'm a bit confused about the STG-machine Registers. First, as shown in the GHC wiki e.g. https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/haskell-execution/registers , the STG-machine has some virtual registers that are mapped to real registers, such as Base, Sp, SpLim, Hp, Rn, Fn and Dn, but unfortunately the mapping logic of the STG registers is not explained in detail here. Then I tried to read the source files of various platforms in rts/include/stg/MachRegs. At first I thought they were mapped using the callee saved registers, such as aarch64, ppc, loongarch64 and riscv64 platforms, but this seems broken on s390x and x86_64 platforms. so now I have two questions: 1. What determines the amounts of Rn, Fn and Dn for different platforms? As for Rn, aarch64 has 6 registers, loongarch64 has 5 registers, ppc has 10 registers, and riscv64 has 7 registers. As for Fn, both aarch64 and loongarch64 have 4 registers, and both ppc and riscv64 have 6 registers. 2. What is the basic rule to assign the actual processor registers to the STG machine registers? The aarch64, loongarch64, ppc and riscv64 platforms seem to have a 'normal' mapping, while the s390x and x86_64 platforms have an 'non-normal' mapping e.g. R4~R8, F5~F6 and D5~D6 in s390x use the caller saved registers. Does this mean that the caller saved registers for passing argument can be used for mapping when the callee saved registers are insufficient? Thanks, Dashiell -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Dec 18 20:07:45 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 18 Dec 2023 15:07:45 -0500 Subject: STG register mapping In-Reply-To: <77ac4cba.f38.18c71e8ce39.Coremail.dashiellwill@163.com> References: <77ac4cba.f38.18c71e8ce39.Coremail.dashiellwill@163.com> Message-ID: <877clbff5d.fsf@smart-cactus.org> DashiellWill writes: > Hi all, > > > I'm newbie at GHC, trying to read the source code and understand the design of GHC. > Now I'm learning about the Haskell Execution Model, but now I'm a bit confused about the STG-machine Registers. > Hello! > > First, as shown in the GHC wiki e.g. https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/haskell-execution/registers , > the STG-machine has some virtual registers that are mapped to real registers, such as Base, Sp, SpLim, Hp, Rn, Fn and Dn, > but unfortunately the mapping logic of the STG registers is not explained in detail here. > > > Then I tried to read the source files of various platforms in rts/include/stg/MachRegs. > At first I thought they were mapped using the callee saved registers, such as aarch64, ppc, loongarch64 and riscv64 platforms, > but this seems broken on s390x and x86_64 platforms. > > > so now I have two questions: > 1. What determines the amounts of Rn, Fn and Dn for different platforms? > As for Rn, aarch64 has 6 registers, loongarch64 has 5 registers, ppc has 10 registers, and riscv64 has 7 registers. > As for Fn, both aarch64 and loongarch64 have 4 registers, and both ppc and riscv64 have 6 registers. > When possible we do try to map STG global registers to callee-saved platform registers. The reason for this is that foreign calls must save the contents of callee-saved registers, increasing the overhead of unsafe foreign calls. Naturally, callee-saved registers tend to be a fairly scarce resource (e.g. the System V x86-64 ABI only provides r12-15, rsp, rbp, and rbx). Consequently, sometimes there are tricky trade-offs that need to be made. It is quite possible that the current trade-off is not ideal; perhaps mapping global registers to caller-saved registers would be worthwhile, even if this means that foreign calls require a bit more overhead. Afterall, most Haskell programs have significantly more Haskell calls than foreign calls. It would be great if an interested party would reconsider this decision and do some benchmarks. > 2. What is the basic rule to assign the actual processor registers to > the STG machine registers? There isn't much of a rule; most of these assignments are just whatever the original port author specified; the actual assignment really doesn't matter. I'd be happy to answer any further questions. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: