I favor keeping them undeprecated as I currently have code that needs the lack of a Typeable constraint there in cases where the argument plays a similar role to the region parameter for ST s, where it *can't* be made Typeable!

On the plus side, you may be able to eliminate the requirement that the arguments be of kind * though, rather dramatically increasing the utility of gcast1 and gcast2.

-Edward

On Jul 22, 2013, at 5:38 AM, José Pedro Magalhães <jpm@cs.uu.nl> wrote:

Hi,

On Mon, Jul 22, 2013 at 10:19 AM, Richard Eisenberg <eir@cis.upenn.edu> wrote:
There seems to be a small tangle. The proposal includes deprecating gcast1 and gcast2 in favor of the poly-kinded gcast. But, there is a small discrepancy between these. Here are the type signatures:

gcast :: forall a b c. (Typeable a, Typeable b) => c a -> Maybe (c b)
gcast1 :: forall c t t' a. (Typeable (t :: * -> *), Typeable t')
       => c (t a) -> Maybe (c (t' a))

The difference is that gcast1 does *not* require the variable `a` to be Typeable, whereas defining gcast1 = gcast does require this. Not requiring `a` to be Typeable seems correct to me, as the type signature of gcast1 requires both uses of `a` to be the same. But, gcast isn't smart enough to know that. Here are some ideas of how to proceed:

- Keep gcast1 and gcast2 undeprecated.

I'd say we should go for this first option, because the second one is pretty bad.


Cheers,
Pedro
 
- Require clients to add more Typeable constraints (for example, in Data.Data) to get their code to compile with gcast.
- Come up with some other workaround, but none is striking me at the moment.

Thoughts?

Richard


On 2013-07-22 09:44, Richard Eisenberg wrote:
I was waiting to respond to Shachaf's email saying "pushed", but
instead, I have to say "currently validating".

Expect this by the end of the day. Sorry it's taken so long!

Richard

On 2013-07-22 09:23, José Pedro Magalhães wrote:
Thanks for bringing this up again. This was started in my data-proxy
branch of base [1],
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 :-)

Thanks,
Pedro

On Sun, Jul 21, 2013 at 3:09 AM, Shachaf Ben-Kiki <shachaf@gmail.com>
wrote:

On Mon, Mar 4, 2013 at 11:12 AM, José Pedro Magalhães
<jpm@cs.uu.nl> wrote:
Hi,

On Mon, Mar 4, 2013 at 4:51 PM, Richard Eisenberg
<eir@cis.upenn.edu> wrote:

Unless I'm missing something, this all looks very
straightforward. The
implementation is there, already, in the guise of (gcast Refl).
We would
just shuffle the definitions around a bit. Am I indeed missing
something?


I think that is the case indeed. Though I agree that it would be
a nice
addition to Data.Typeable.



This thread is a few months old now, but it looks like people were
generally in favor of adding (gcast Refl) to Data.Typeable. I've
used
it in real code in at least one place since then (where I just
defined
it locally). It doesn't look like it's actually been added, though
--
is it planned to go into HEAD eventually?

    Shachaf



Links:
------
[1] https://github.com/ghc/packages-base/tree/data-proxy

_______________________________________________
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