The motivation for the existing Proxy behavior was so we consistently never pattern match on a Proxy at all. The major usecase of Proxy is to replace existing undefined values. If we start pattern matching on them then there become more places in the code that have to ask something to evaluate, and there become potential performance trade-offs for users switching to Proxy from undefined.
On Wed, Jul 31, 2013 at 09:38:06AM +0100, Richard Eisenberg wrote:My instinct is to disagree. It's like how case with a single pattern is still strict -- I expect (==) to do some work even if in principle it doesn't have to. And indeed if () behaves that way I would expect Proxy to do the same.
As for the instances' behavior being different from GHC's generated versions, I think the lazier ones (as implemented) are probably more useful.
I'm not critically affected by the decision one way or the other though, so don't disrupt anything on my account.
If I don't hear otherwise by the end of the day, I'll push these changes.
Richard
On 2013-07-31 00:35, Edward Kmett wrote:
I would really want to keep asProxyTypeOf around as it is commonly
used and has no other plausible home within tagged.
reproxy is quite negotiable.
Ever since its signature was generalized a version or two ago in
tagged, it has started to feel quite silly.
If I move
coerce :: (Functor f, Contravariant f) => f a -> f b
coerce = contramap absurd . fmap absurd -- using absurd from 'void'
-- or equivalently: coerce = contramap (const ()) . fmap (const ())
from lens up into the contravariant package, then the role that
function plays can be replaced entirely with that more general purpose
combinator in "user land" without needing any funny looking functions
in base.
Proxy is both Contravariant and a normal covariant Functor as it
doesn't use its argument, just like Const m. reproxy originally
witnessed this fact just for Proxy, but that fact in its broader
generality has since been exploited to make getters and folds in lens,
so reproxy is basically just residue of an old approach.
-Edward
On Tue, Jul 30, 2013 at 6:44 PM, Shachaf Ben-Kiki <shachaf@gmail.com>
wrote:
On Mon, Jul 22, 2013 at 1:23 AM, José Pedro Magalhães
<jpm@cs.uu.nl> wrote:
Thanks for bringing this up again. This was started in mydata-proxy branch
of base,7.8, and I
but never really finished. We definitely want to have this in
think there'sinstances we
only some minor finishing work to do (check if we have all the
want,already, and what
document, etc.). Perhaps you can look through what's there
youpatches too :-)
think is missing? I'm more than happy to accept contributing
I'm looking at the current state of Data.Proxy in base (it looks
like
Richard merged data-proxy into master) and it looks pretty good
instance-wise. Issues I'm aware of:
* It looks like there's a SafeHaskell issue -- should this be
marked
Trustworthy? See https://github.com/ekmett/tagged/pull/13 [1]
* tagged's Data.Proxy defines some useful functions that aren't
present in base. Two of them can move into tagged's Data.Tagged,
but
the other two should probably go in base's Data.Proxy. In
particular
asProxyTypeOf :: a -> proxy a -> a
asProxyTypeOf = const
reproxy :: proxy s -> Proxy t
reproxy _ = Proxy
When these are fixed, tagged can probably shuffle a couple of
functions around and then use base's Data.Proxy rather than
exporting
its own module (for GHC ≥ 7.7).
(By the way: Some instances are slightly different from what GHC
would
derive -- e.g. «_ == _ = True» is different from «Proxy == Proxy
=
True», which is ()'s Eq behavior. I think this is OK but I wanted
to
mention it.)
Thanks,
Shachaf
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries [2]
Links:
------
[1] https://github.com/ekmett/tagged/pull/13
[2] http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
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