Re: Proxy and new-typeable

20 Mar 2013

      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  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  [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 
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 
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 
...
José Pedro Magalhães  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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
...
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries