Upload new Hackage version compatible with GHC 9.2.5

[ltbinsbe]

Building library for TypeCompose-0.9.14..
[ 1 of 10] Compiling Control.Instances ( src/Control/Instances.hs, dist/build/Control/Instances.o, dist/build/Control/Instances.dyn_o )
[ 2 of 10] Compiling Data.Bijection   ( src/Data/Bijection.hs, dist/build/Data/Bijection.o, dist/build/Data/Bijection.dyn_o )
[ 3 of 10] Compiling Control.Compose  ( src/Control/Compose.hs, dist/build/Control/Compose.o, dist/build/Control/Compose.dyn_o )

src/Control/Compose.hs:221:22: warning: [-Wstar-is-type]
    Using ‘*’ (or its Unicode variant) to mean ‘Data.Kind.Type’
    relies on the StarIsType extension, which will become
    deprecated in the future.
    Suggested fix: use ‘Type’ from ‘Data.Kind’ instead.
    |
221 | newtype ((g :: k2 -> *) :. (f :: k1 -> k2)) (a :: k1)
    |                      ^

src/Control/Compose.hs:748:10: warning: [-Wsimplifiable-class-constraints]
    • The constraint ‘Show (f a, g a)’ matches
        instance (Show a, Show b) => Show (a, b) -- Defined in ‘GHC.Show’
      This makes type inference for inner bindings fragile;
        either use MonoLocalBinds, or simplify it using the instance
    • In the instance declaration for ‘Show ((f :*: g) a)’
    |
748 | instance (Show (f a, g a)) => Show ((f :*: g) a) where
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Control/Compose.hs:751:10: warning: [-Wsimplifiable-class-constraints]
    • The constraint ‘Eq (f a, g a)’ matches
        instance (Eq a, Eq b) => Eq (a, b)
          -- Defined in ‘ghc-prim:GHC.Classes’
      This makes type inference for inner bindings fragile;
        either use MonoLocalBinds, or simplify it using the instance
    • In the instance declaration for ‘Eq ((f :*: g) a)’
    |
751 | instance (Eq (f a, g a)) => Eq ((f :*: g) a) where
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Control/Compose.hs:754:10: warning: [-Wsimplifiable-class-constraints]
    • The constraint ‘Ord (f a, g a)’ matches
        instance (Ord a, Ord b) => Ord (a, b)
          -- Defined in ‘ghc-prim:GHC.Classes’
      This makes type inference for inner bindings fragile;
        either use MonoLocalBinds, or simplify it using the instance
    • In the instance declaration for ‘Ord ((f :*: g) a)’
    |
754 | instance (Ord (f a, g a)) => Ord ((f :*: g) a) where
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ 4 of 10] Compiling Data.Lambda      ( src/Data/Lambda.hs, dist/build/Data/Lambda.o, dist/build/Data/Lambda.dyn_o )
[ 5 of 10] Compiling Data.Pair        ( src/Data/Pair.hs, dist/build/Data/Pair.o, dist/build/Data/Pair.dyn_o )

src/Data/Pair.hs:98:10: error:
    • Non type-variable argument in the constraint: Monoid_f (Flip j o)
      (Use FlexibleContexts to permit this)
    • In the instance declaration for ‘Pair (Flip j o)’
   |
98 | instance (Arrow j, Monoid_f (Flip j o)) =>
   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
Error: cabal: Failed to build TypeCompose-0.9.14

[conal]

Thanks for the error report. This library is very old, and mostly superseded (e.g., by GHC.Generics), afaik. Are you using it?

[ltbinsbe]

Yes indeed, as part of the `gll` library which itself is used in several of my other projects. Would you suggest migrating away from TypeCompose? I have no idea how involved that would be. Many thanks for your quick response.

…

________________________________ From: Conal Elliott ***@***.***> Sent: Thursday, December 1, 2022 10:21:25 PM To: conal/TypeCompose ***@***.***> Cc: L. Thomas van Binsbergen ***@***.***>; Author ***@***.***> Subject: Re: [conal/TypeCompose] Upload new Hackage version compatible with GHC 9.2.5 (Issue #12) Thanks for the error report. This library is very old, and mostly superseded (e.g., by GHC.Generics), afaik. Are you using it? — Reply to this email directly, view it on GitHub<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fconal%2FTypeCompose%2Fissues%2F12%23issuecomment-1334460412&data=05%7C01%7Cl.t.vanbinsbergen%40uva.nl%7C1fd3971a3f284892bee308dad3e2033b%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C638055264919638244%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iyy3pH2VPPRese5A9Lve2CP5mS2NGomHMsOe0Mi0U4Q%3D&reserved=0>, or unsubscribe<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABAKRF6QXAQDP7ORWDRY7SDWLEJFLANCNFSM6AAAAAASREOL64&data=05%7C01%7Cl.t.vanbinsbergen%40uva.nl%7C1fd3971a3f284892bee308dad3e2033b%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C638055264919638244%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j%2F4fDvOMCvNWeZw1tMjhyR802fG9FGy2NC0yCx0jZNc%3D&reserved=0>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[conal]

Would you suggest migrating away from TypeCompose?

It's worth exploring. I wrote TypeCompose to capture some useful patterns involving functor algebra that came up often for me. Later, GHC.Generics provided much of that functionality and gave it just enough compiler support ("deriving Generic") to be very convenient. I switched to that functionality for my own work, e.g., Generic functional parallel algorithms: Scan and FFT. (Now I'm doing something analogous in Agda, which is a much more natural setting for generic/polytypic programming.)

I have no idea how involved that would be.

I just looked at the gll source. It appears to use only OO from Control.Compose:

-- | Composition of type constructors: unary with binary.  Called
-- "StaticArrow" in [1].
newtype OO f j a b = OO { unOO :: f (a `j` b) }

#if __GLASGOW_HASKELL__ >= 609
instance (Applicative f, Category cat) => Category (OO f cat) where
  id          = OO (pure id)
  OO g . OO h = OO (liftA2 (.) g h)
#endif

instance (Applicative f, Arrow arr) => Arrow (OO f arr) where
#if __GLASGOW_HASKELL__ < 609
  OO g >>> OO h = OO (liftA2 (>>>) g h)
#endif
  arr           = OO . pure . arr
  first (OO g)  = OO (liftA first g)

That OO type construction (which I'd forgotten) is not in GHC.Generics. I think that "[1]" is meant to be Applicative Programming with Effects. Sure enough, this construction is in Control.Arrow.Transformer.Static.

You're most welcome to copy the OO code above and use it in gll. Better for you, however, might be to use StaticArrow instead so you have a little less code to maintain.

Good luck, and please let me know how it comes out.

-- Conal

[ltbinsbe]

Many thanks for taking the effort to investigate the matter so thoroughly! A first attempt revealed that by using StaticArrow I will now need to give Arrow and Category instances for at least one of my types that I did not need for OO. I need to dive deeper to see if this raises any problems.

…

________________________________ From: Conal Elliott ***@***.***> Sent: 02 December 2022 01:00 To: conal/TypeCompose ***@***.***> Cc: L. Thomas van Binsbergen ***@***.***>; Author ***@***.***> Subject: Re: [conal/TypeCompose] Upload new Hackage version compatible with GHC 9.2.5 (Issue #12) Would you suggest migrating away from TypeCompose? It's worth exploring. I wrote TypeCompose to capture some useful patterns involving functor algebra that came up often for me. Later, GHC.Generics provided much of that functionality and gave it just enough compiler support ("deriving Generic") to be very convenient. I switched to that functionality for my own work, e.g., Generic functional parallel algorithms: Scan and FFT<https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fconal.net%2Fpapers%2Fgeneric-parallel-functional&data=05%7C01%7Cl.t.vanbinsbergen%40uva.nl%7Cae8b1e872f514ce366fb08dad3f8439b%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C638055360495610392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YtzfcJyX8Kk7Ru0N6ehvHaJeG9IalhV02fgYdeZaB9c%3D&reserved=0>. (Now I'm doing something analogous in Agda, which is a much more natural setting for generic/polytypic programming.) I have no idea how involved that would be. I just looked at the gll source. It appears to use only OO from Control.Compose:

-- | Composition of type constructors: unary with binary. Called -- "StaticArrow" in [1]. newtype OO f j a b = OO { unOO :: f (a `j` b) } #if __GLASGOW_HASKELL__ >= 609 instance (Applicative f, Category cat) => Category (OO f cat) where id = OO (pure id) OO g . OO h = OO (liftA2 (.) g h) #endif instance (Applicative f, Arrow arr) => Arrow (OO f arr) where #if __GLASGOW_HASKELL__ < 609 OO g >>> OO h = OO (liftA2 (>>>) g h) #endif arr = OO . pure . arr first (OO g) = OO (liftA first g) That OO type construction (which I'd forgotten) is not in GHC.Generics. I think that "[1]" is meant to be Applicative Programming with Effects<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.staff.city.ac.uk%2F~ross%2Fpapers%2FApplicative.html&data=05%7C01%7Cl.t.vanbinsbergen%40uva.nl%7Cae8b1e872f514ce366fb08dad3f8439b%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C638055360495610392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gcC7nvnx%2Bxf8b8b28SGKkfeZHgX0HwmhrvD0PTXC844%3D&reserved=0>. Sure enough, this construction is in Control.Arrow.Transformer.Static<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Farrows-0.4.4.2%2Fdocs%2FControl-Arrow-Transformer-Static.html%23t%3AStaticArrow&data=05%7C01%7Cl.t.vanbinsbergen%40uva.nl%7Cae8b1e872f514ce366fb08dad3f8439b%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C638055360495610392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ctOUpJMJr%2F8Nnug%2B6mnIe8a1VQp2xkf6BTTZKmxO35A%3D&reserved=0>. You're most welcome to copy the OO code above and use it in gll. Better for you, however, might be to use StaticArrow instead so you have a little less code to maintain. Good luck, and please let me know how it comes out.

-- Conal — Reply to this email directly, view it on GitHub<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fconal%2FTypeCompose%2Fissues%2F12%23issuecomment-1334595426&data=05%7C01%7Cl.t.vanbinsbergen%40uva.nl%7Cae8b1e872f514ce366fb08dad3f8439b%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C638055360495610392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UUlPE84wZp7LFW5jujuzqYL78%2BvU8Jw1NSKVKIlTxhY%3D&reserved=0>, or unsubscribe<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABAKRF4TF4IDRECWC3SAWXDWLE32VANCNFSM6AAAAAASREOL64&data=05%7C01%7Cl.t.vanbinsbergen%40uva.nl%7Cae8b1e872f514ce366fb08dad3f8439b%7Ca0f1cacd618c4403b94576fb3d6874e5%7C0%7C0%7C638055360495610392%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K9RQc7Z%2BuiuE9%2F1JOjmQ76clrjBhiHgfJgOYiiQtBkQ%3D&reserved=0>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ltbinsbe]

For the time being I have followed your first suggestion and copied over the needed definition of OO

[conal]

A first attempt revealed that by using StaticArrow I will now need to give Arrow and Category instances for at least one of my types that I did not need for OO.

Odd. On inspection, StaticArrow and OO appear to have exactly the same requirements for constructing and for Category and Arrow instances. ¯\_(ツ)_/¯

[conal]

If you figure out the source of the difference, I'd love to hear.

[ltbinsbe]

The missing instance error was triggered by the use of unWrap instead of unOO

[conal]

Oho! Thanks for the explanation. A questionable choice for the type of unWrap.

It sounds like you were not using the Category or Arrow instances for OO (which would have made the same demand). In that case, all you'd need to copy is the OO definition itself, which is probably a good way to go.

[ltbinsbe]

Yes, I went this route. Just published a new version of the gll library. Now updating the packages downstream 🤞

Thanks again for your help and interest.

[Bodigrim]

As a Hackage trustee I made revisions to prohibit unbuildable configurations:
https://hackage.haskell.org/package/TypeCompose-0.9.13/revisions/
https://hackage.haskell.org/package/TypeCompose-0.9.14/revisions/

[smunix]

As a Hackage trustee I made revisions to prohibit unbuildable configurations: https://hackage.haskell.org/package/TypeCompose-0.9.13/revisions/ https://hackage.haskell.org/package/TypeCompose-0.9.14/revisions/

The build issues reported here with ghc925 were already fixed, see #11.

@conal I think it's still worth pushing a new version (0.9.15?) to hackage, as multiple other packages have a transitive dependency landing on TypeCompose. What do you think?

[conal]

As a Hackage trustee I made revisions to prohibit unbuildable configurations: https://hackage.haskell.org/package/TypeCompose-0.9.13/revisions/ https://hackage.haskell.org/package/TypeCompose-0.9.14/revisions/

The build issues reported here with ghc925 were already fixed, see #11.

@conal I think it's still worth pushing a new version (0.9.15?) to hackage, as multiple other packages have a transitive dependency landing on TypeCompose. What do you think?

@smunix I think it would be healthier for the community to drop TypeCompose for more modern, complete, and robust alternatives. By not updating TypeCompose, we're more likely to evaluate each current use as the current situation becomes problematic for those uses, as with @ltbinsbe above. If there are any remaining wise uses of TypeCompose, the strategy I'm suggesting will surface them.

[conal]

Do we (Hackage users) have successful and recommended strategies for deprecating currently used packages?