Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#9639 closed task (fixed)

Remove OldTypeable

Reported by: dreixel Owned by:
Priority: normal Milestone: 7.10.1
Component: Compiler Version: 7.9
Keywords: Typeable Cc: ekmett
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D311
Wiki Page:


I think it's safe to remove Data.OldTypeable now. It's been deprecated in 7.8, and we said that we'd remove it for 7.10. This ticket is to record that task, and to check that there are no objections to removing it.

Change History (18)

comment:1 Changed 5 years ago by mgmeier

Differential Rev(s): Phab:D311
Status: newpatch

comment:2 Changed 5 years ago by hvr

Cc: ekmett added
Milestone: 7.10.1

comment:3 Changed 5 years ago by ekmett

I'd personally prefer to wait for 7.12 to allow folks who have longer support cycles to catch up unless it is causing an active pain point for us in maintenance.

comment:4 Changed 5 years ago by dreixel

Do we know of anyone actually using this? We've warned it would be removed in 7.10.

I don't think it causes much maintenance issues, but that alone shouldn't be a reason to keep it around.

comment:5 Changed 5 years ago by ekmett

My knee jerk _was_ to actually remove it, but then I looked with a quick google search and there is at least type-eq still using it, with a somewhat confused upgrade path, and explicit "future uncertain" comments in the code, which has dependencies upon it splintering out through haskell-names and fay, etc.

comment:6 Changed 5 years ago by hvr

Fwiw, if everything goes according to plan, the GHC 7.11 branch will open up in roughly 6 weeks... so that's probably the upper bound for OldTypeable's time-to-live, if we can't sort out the type-eq issue in time for GHC 7.10.1

Last edited 5 years ago by hvr (previous) (diff)

comment:7 Changed 5 years ago by mgmeier

The only reason for haskell-names to use the type-eq package seems to be in its module Language.Haskell.Names.Annotated:

-- This should be incorporated into Data.Typeable soon
import Type.Eq

using dynamicEq and (:~:) from that import.

Does the current Data.Typeable facilitate this functionality yet? If so, type-eq dependency could be dropped from haskell-names (and fay, in consequence), as far as I can see.

comment:8 Changed 5 years ago by snoyberg

Herbert asked me to weigh in with some data from Stackage builds. Here's what I wrote to him:

I have a Stackage build running on my system right now in the testing phase, so I have access to all of the log files. This is a Stackage 7.8.3 + Haskell Platform build, so it uses a few less packages than the normal 7.8 and has a few older packages (I can test on 7.8 w/o HP as well if it would be useful). Of 651 packages built in this run, only two of the logs mentioned the string OldTypeable. type-eq (version 0.4.2) certainly has the deprecation warning in many places. haskell-names mentions OldTypeable as well, but it seems to simply be dealing with all of the files in base, not a real dependency.

If any other data from Stackage would be useful, let me know.

comment:9 Changed 5 years ago by dreixel

I don't see what's the issue with type-eq. Simply changing the imports in Type.Eq.Poly and Type.Eq.Higher from

import Data.OldTypeable hiding (cast)


import Data.Typeable hiding (cast, (:~:))

seems to work.

If this is the only example we could find on Hackage, I think it's safe to go ahead and remove OldTypeable.

comment:10 Changed 5 years ago by ekmett

I have no objection to pulling the plug.

comment:11 Changed 5 years ago by dreixel

I have only one concern: the patch also removes Typeable{1..7}. Michael, could you perhaps check how much code is using these (deprecated) classes?

comment:12 Changed 5 years ago by ekmett


A quick skim of my own projects reveals 100+ locations affected in a way that makes them very awkward to patch around with CPP, as they affect public APIs and I've currently agreed to maintain many of my packages back to ghc 7.4 -- an agreement that will bump to 7.6 upon the release of 7.10, etc.

So as a data point, deleting those 20 lines will cost me personally several hundred lines worth of easily-screwed-up support work if it is done as part of GHC 7.10.

comment:13 Changed 5 years ago by mgmeier

I agree with dreixel and ekmett on this one. After doing some checking, it doesn't seem like a good idea to remove these deprecated types yet. Does anyone happen to know when or why it was decided to deprecate them, or where to read up on that (mailarchive/forum)?

I'll revert the phab diff with arcanist accordingly, as soon as I figure out how ;)

comment:14 in reply to:  13 Changed 5 years ago by hvr

Replying to mgmeier:

Does anyone happen to know when or why it was decided to deprecate them, or where to read up on that (mailarchive/forum)?

I can point you to 0c7507a09bfac5710b76eb4c1517789ce3b3a3ff ...

comment:15 Changed 5 years ago by ekmett

They definitely belong deprecated, it is just a matter that we shouldn't be so quick to remove them.

comment:16 Changed 5 years ago by Herbert Valerio Riedel <hvr@…>

In 7369d2595a8cceebe457a44c8400828f4df87ea0/ghc:

Remove obsolete Data.OldTypeable (#9639)

This finally removes the `Data.OldTypeable` module (which
has been deprecated in 7.8), from `base`, compiler and testsuite.

The deprecated `Typeable{1..7}` aliases in `Data.Typeable` are not
removed yet in order to give existing code a bit more time to adapt.

Reviewed By: hvr, dreixel

Differential Revision:

comment:17 Changed 5 years ago by hvr

Keywords: Typeable added
Resolution: fixed
Status: patchclosed

comment:18 Changed 5 years ago by dreixel

And thanks @mgmeier!

Note: See TracTickets for help on using tickets.