Proxy and new-typeable

[Ben Gamari]

Roman Cheplyaka <roma at ro-che.info> writes:

> Right now Data.Typeable is proxy-agnostic. The proposal is just to
> export a Proxy type for convenience (alternatively, the user can define
> her own Proxy or use one from tagged).
> What exactly forces you to support both proxies in your code?
>
> (I'm reluctant to have many proxy types scattered around mainly because
> of unnecessary name conflicts, but I'd like to understand your concerns
> too.)
>
It seems the options before us are,

  a) Use Proxy strictly internally in Data.Typeable. In this case users
     will continue to use the Proxy types in tagged and elsewhere as they
     already happily do

  b) Export Proxy from Data.Typeable in its current state, accepting
     that users relying on external Proxy types will need to either
     accept a loss of functionality, explicitly hide Typeable's Proxy,
     or rely on orphan instances

  c) Find a way to bring Typeable's Proxy type to a level of
     functionality comparable to that currently available outside of
     base

Having tried to compile a good amount of code using Data.Typeable's
Proxy, it seems clear to me that (b) is the worst of the three
outcomes. There are a good number of packages which rely on the
instances provided by external Proxy types. Removing these will bring
great deal of pain in the short turn and pose a large maintenance burden
moving forward.

Tonight I tried to implement (c) but found that this might be
quite tricky without establishing some very brittle cyclic imports in
base. As it stands, nearly everything in base imports Typeable
somehow. Requiring Typeable to in turn import Applicative, Foldable,
Traversable, and others places some very unfortunate cycles in the
dependency structure. Even after an hour of hacking and 200 lines of
changes, I still hadn't succeeded in getting base to build with a
reasonable set of Proxy instances (although, admittedly, this might just
be due to my inexperience with this sort of issue).

In light of these points, I believe that (a) is the course of least
pain. Those users that need Proxy already happily rely on
packages outside of base. Meanwhile base can use its own (necessarily
minimal) Proxy internally without issue. This approach requires minimal
changes in base and avoids unnecessary breakage of user code, all while
depriving no one of current or future functionality. Admittedly, there
may be a couple more Proxy types in the namespace than would otherwise
exist, but this seems like a small price to pay to avoid the breakage
and pain of (b) and (c) above.

Cheers,

- Ben