new-typeable, new cast?

[Edward Kmett]

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.

-Edward

On Wed, Jul 31, 2013 at 11:06 AM, Ben Millwood <haskell at benmachine.co.uk>wrote:

> On Wed, Jul 31, 2013 at 09:38:06AM +0100, Richard Eisenberg wrote:
>
>> As for the instances' behavior being different from GHC's generated
>> versions, I think the lazier ones (as implemented) are probably more useful.
>>
>
> 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.
>
> 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 at gmail.com>
>>> wrote:
>>>
>>>  On Mon, Jul 22, 2013 at 1:23 AM, José Pedro Magalhães
>>>> <jpm at cs.uu.nl> wrote:
>>>>
>>>>> Thanks for bringing this up again. This was started in my
>>>>>
>>>> data-proxy branch
>>>>
>>>>> of base,
>>>>> but never really finished. We definitely want to have this in
>>>>>
>>>> 7.8, and I
>>>>
>>>>> think there's
>>>>> only some minor finishing work to do (check if we have all the
>>>>>
>>>> instances we
>>>>
>>>>> want,
>>>>> document, etc.). Perhaps you can look through what's there
>>>>>
>>>> already, and what
>>>>
>>>>> you
>>>>> think is missing? I'm more than happy to accept contributing
>>>>>
>>>> patches too :-)
>>>>
>>>>>
>>>>>
>>>>>
>>>> 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<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 at haskell.org
>>>> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>[2]
>>>>
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] https://github.com/ekmett/**tagged/pull/13<https://github.com/ekmett/tagged/pull/13>
>>> [2] http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>>>
>>> ______________________________**_________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>>>
>>
>> ______________________________**_________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130731/87592f6d/attachment.htm>