Annotating instances

Simon Peyton Jones simon.peytonjones at gmail.com
Mon Dec 4 12:07:38 UTC 2023


> 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.angermann at 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.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
>> <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.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
>>>> <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.reinders at 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 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20231204/d2f1eb33/attachment.html>


More information about the ghc-devs mailing list