My main concern is that many of the modules I import Proxy in already import Typeable.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>The existing Data.Proxy has been used as the representation of Data.Tagged as a representable profunctor. It serves as a trivial Applicative, etc.</div><div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div>1.) Continuing to support Data.Proxy, which is now completely redundant except for the fact that I have more instances for standard types.</div><div><br></div><div>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.</div>
<div><br></div><div>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 <i>all</i> the instances. =)</div>
<div><br></div><div>-Edward<br><br><div class="gmail_quote">On Wed, Mar 20, 2013 at 5:17 AM, Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right now Data.Typeable is proxy-agnostic. The proposal is just to<br>
export a Proxy type for convenience (alternatively, the user can define<br>
her own Proxy or use one from tagged).<br>
What exactly forces you to support both proxies in your code?<br>
<br>
(I'm reluctant to have many proxy types scattered around mainly because<br>
of unnecessary name conflicts, but I'd like to understand your concerns<br>
too.)<br>
<br>
Roman<br>
<br>
* Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> [2013-03-20 04:48:49-0400]<br>
<div class="im">> If you insist on adding Proxy to Data.Typeable, I'd like to strongly<br>
> suggest that we might want to look at promoting Data.Proxy from the tagged<br>
> package to base.<br>
><br>
> It offers a lot of instances that I currently rely upon in production code<br>
> and is already in use in a large portion of the ~42 reverse dependencies of<br>
> that package:<br>
><br>
> <a href="http://packdeps.haskellers.com/reverse/tagged" target="_blank">http://packdeps.haskellers.com/reverse/tagged</a><br>
><br>
> Of course we could invert the dependencies from packages outside of base at<br>
> that time.<br>
><br>
</div>> Exporting a crippled Proxy from Data.Typeable *without* those instances<br>
<div class="HOEnZb"><div class="h5">> will basically just ensure that I need to somehow support both, fight<br>
> needlessly with orphans and/or deal with qualified imports everywhere, and<br>
> it will break about 3 dozen modules of mine, and impact others.<br>
><br>
> All in all this makes me personally rather strongly opposed to the idea of<br>
> just randomly throwing a Proxy type in the module without ensuring we don't<br>
> lose existing functionality along the way.<br>
><br>
> -Edward<br>
><br>
> On Wed, Mar 20, 2013 at 4:04 AM, José Pedro Magalhães <<a href="mailto:jpm@cs.uu.nl">jpm@cs.uu.nl</a>> wrote:<br>
><br>
> > Data.Typeable no longer uses Proxy, yet I think it is convenient to have a<br>
> > Proxy datatype<br>
> > defined somewhere in base, and re-export it from Data.Typeable, as you<br>
> > might often often<br>
> > want to use it.<br>
> ><br>
> ><br>
> > Cheers,<br>
> > Pedro<br>
> ><br>
> ><br>
> > On Wed, Mar 20, 2013 at 12:35 AM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
> ><br>
> >> +1 for finding a resolution. The idea of another Proxy floating around<br>
> >> fills me with unease.<br>
> >><br>
> >> -Edward<br>
> >><br>
> >> On Tue, Mar 19, 2013 at 7:48 PM, Ben Gamari <<a href="mailto:bgamari.foss@gmail.com">bgamari.foss@gmail.com</a>>wrote:<br>
> >><br>
> >>> José Pedro Magalhães <<a href="mailto:jpm@cs.uu.nl">jpm@cs.uu.nl</a>> writes:<br>
> >>><br>
> >>> > Yes, it's entirely unproblematic, and a good suggestion.<br>
> >>> ><br>
> >>> What happened to this proposal? As far as I can tell the new-typeable<br>
> >>> work is in (or rather, the branch has been deleted) yet Data.Typeable<br>
> >>> still seems to have its own Proxy. Given that there has been talk of a<br>
> >>> 7.8 release, this should probably be resolved quickly (although it's not<br>
> >>> clear to me from the massive thread where that discussion concluded).<br>
> >>><br>
> >>> Cheers,<br>
> >>><br>
> >>> - Ben<br>
> >>><br>
> >>> _______________________________________________<br>
> >>> Libraries mailing list<br>
> >>> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> >>> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
> >>><br>
> >><br>
> >><br>
> ><br>
<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br>
</div></div></blockquote></div><br></div>