Proxy and new-typeable

[Edward Kmett]

On Fri, Mar 22, 2013 at 12:03 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:

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

You don't need to make it cyclic, if the edge already exists one way in the
graph just follow it back and put the instance with the class.


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

I would be happy with (a) or (c).

That said, given (c) I could make Data.Proxy in tagged re-export the
Data.Typeable Proxy whenever we're on a new enough GHC and I can invert all
the other dependency edges. It'll be work for me, but it means that when a
user goes to mix the existing tagged Proxy with code from Data.Typeable it
'just works' and there aren't two types named Proxy floating around that'll
have lots of users.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130322/6f14a466/attachment-0001.htm>