"Merge-buddy" response

[Alan & Kim Zimmerman]

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Annotating instances

[Simon Peyton Jones]

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.peytonjo...@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.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
 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
>> 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 

Re: Annotating instances

[Moritz Angermann]

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.peytonjo...@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.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
>>> 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
> 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@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
>

Re: Annotating instances

[Simon Peyton Jones]

> 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.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
>> 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.peytonjo...@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@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

Re: Annotating instances

[Moritz Angermann]

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
> 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.peytonjo...@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@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

Re: Annotating instances

[Simon Peyton Jones]

>
> 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.peytonjo...@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@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

Re: Annotating instances

[Moritz Angermann]

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
> 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@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

Re: Annotating instances

[Simon Peyton Jones]

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@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