Upload new Hackage version compatible with GHC 9.2.5 about typecompose HOT 17 OPEN

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.

from typecompose.

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.

from typecompose.

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

Noted, thanks. It turns out the O composition is equivalent to Data.Functor.Compose in base; so I went ahead and removed TypeCompose from spatial-math. See the PR above ^

from typecompose.

Flip appears to have a suitable replacement in the bifunctors package.

from typecompose.

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

from typecompose.

from typecompose.

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

from typecompose.

from typecompose.

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

from typecompose.

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. ¯\_(ツ)_/¯

from typecompose.

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

from typecompose.

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

from typecompose.

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.

from typecompose.

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/

from typecompose.

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?

from typecompose.

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

from typecompose.

Noted, thanks. It turns out the O composition is equivalent to Data.Functor.Compose in base; so I went ahead and removed TypeCompose from spatial-math. See the PR above ^

Perfect! TypeCompose pre-dates Data.Functor.Compose and GHC.Generics, and I switched over to the modern replacements for my own work many years ago.

Thanks for letting me know of the happy outcome, @smunix!

from typecompose.