> 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 <moritz.angerm...@gmail.com> 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.peytonjo...@gmail.com> wrote: > >> Luckily Hlint also support HLINT instead which removed the TH pipeline. >>> >> >> Where is this described/documented? All I can see here >> <https://github.com/ndmitchell/hlint#readme>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.angerm...@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.peytonjo...@gmail.com> wrote: >>> >>>> The whole ANN mechanism >>>> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/extending_ghc.html?highlight=ann#source-annotations>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 <jaro.reind...@gmail.com> >>>> 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@haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs