Proxy and new-typeable

[Edward Kmett]

My main concern is that many of the modules I import Proxy in already
import Typeable.

So if we're going to pick up the functionality of having a 'standard'
Proxy, I'd rather not lose the functionality of having it trivially
Applicative, Eq, Ord, even Enum and Bounded, etc. makes it much easier to
work with in practice, and useful for many situations you wouldn't
immediately expect.

Yes, Typeable is Proxy-agnostic, but the moment you standardize on
something like that the immediate second order consequence is I get 20
emails from people asking me why I'm not using the standard one.

If we can agree to implement all the instances we can sanely implement for
Proxy (and yes, there are a lot of non-obvious ones) then this is a
non-issue.

If Proxy is just something where you intend to offer a minimalist interface
explicitly for the narrow use case you've currently envisioned, then I
would ague that in my experience that assuming you know how something will
be used is a great way to screw over users.

The existing Data.Proxy has been used as the representation of Data.Tagged
as a representable profunctor. It serves as a trivial Applicative, etc.

If you add Proxy to Typeable, if its done by bringing the existing
Data.Proxy module into base (sans a few of my more peculiar non-base
instances) and then re-exporting it from Data.Typeable then my upgrade path
is that I emit a new version of 'tagged' without Proxy and I add version
conditional exports of all of my other instances to those modules. Existing
users of Data.Proxy can then easily support versions before and after GHC
7.7 and no functionality is lost.

If you add Proxy to Typeable and do not do so, then it is less than useful
to me as it fragments the existing users between two different types, and
gives me no story for how I straddle support for pre 7.7 and post-7.7 GHC.
I am locked into a choice between two options:

1.) Continuing to support Data.Proxy, which is now completely redundant
except for the fact that I have more instances for standard types.

2.) If I choose to pay the price of losing the existing functionality in
order to accept a more "standard" version of the type, by having me
re-export it from Data.Proxy in GHC > 7.7 then I lose existing
functionality or have to orphan a ton of instances.

Perhaps my explanation being so long winded has made it seem more
complicated than it is, but really it just comes down to me asking that if
you want Data.Proxy in Typeable, then please make sure to implement
*all*the instances. =)

-Edward

On Wed, Mar 20, 2013 at 5:17 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> 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.)
>
> Roman
>
> * Edward Kmett <ekmett at gmail.com> [2013-03-20 04:48:49-0400]
> > If you insist on adding Proxy to Data.Typeable, I'd like to strongly
> > suggest that we might want to look at promoting Data.Proxy from the
> tagged
> > package to base.
> >
> > It offers a lot of instances that I currently rely upon in production
> code
> > and is already in use in a large portion of the ~42 reverse dependencies
> of
> > that package:
> >
> > http://packdeps.haskellers.com/reverse/tagged
> >
> > Of course we could invert the dependencies from packages outside of base
> at
> > that time.
> >
> > Exporting a crippled Proxy from Data.Typeable *without* those instances
> > will basically just ensure that I need to somehow support both, fight
> > needlessly with orphans and/or deal with qualified imports everywhere,
> and
> > it will break about 3 dozen modules of mine, and impact others.
> >
> > All in all this makes me personally rather strongly opposed to the idea
> of
> > just randomly throwing a Proxy type in the module without ensuring we
> don't
> > lose existing functionality along the way.
> >
> > -Edward
> >
> > On Wed, Mar 20, 2013 at 4:04 AM, José Pedro Magalhães <jpm at cs.uu.nl>
> wrote:
> >
> > > Data.Typeable no longer uses Proxy, yet I think it is convenient to
> have a
> > > Proxy datatype
> > > defined somewhere in base, and re-export it from Data.Typeable, as you
> > > might often often
> > > want to use it.
> > >
> > >
> > > Cheers,
> > > Pedro
> > >
> > >
> > > On Wed, Mar 20, 2013 at 12:35 AM, Edward Kmett <ekmett at gmail.com>
> wrote:
> > >
> > >> +1 for finding a resolution. The idea of another Proxy floating around
> > >> fills me with unease.
> > >>
> > >> -Edward
> > >>
> > >> On Tue, Mar 19, 2013 at 7:48 PM, Ben Gamari <bgamari.foss at gmail.com
> >wrote:
> > >>
> > >>> José Pedro Magalhães <jpm at cs.uu.nl> writes:
> > >>>
> > >>> > Yes, it's entirely unproblematic, and a good suggestion.
> > >>> >
> > >>> What happened to this proposal? As far as I can tell the new-typeable
> > >>> work is in (or rather, the branch has been deleted) yet Data.Typeable
> > >>> still seems to have its own Proxy. Given that there has been talk of
> a
> > >>> 7.8 release, this should probably be resolved quickly (although it's
> not
> > >>> clear to me from the massive thread where that discussion concluded).
> > >>>
> > >>> Cheers,
> > >>>
> > >>> - Ben
> > >>>
> > >>> _______________________________________________
> > >>> Libraries mailing list
> > >>> Libraries at haskell.org
> > >>> http://www.haskell.org/mailman/listinfo/libraries
> > >>>
> > >>
> > >>
> > >
>
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130320/db6a6e77/attachment-0001.htm>