<div>I'm a big fan of this!</div><div><br></div>There aren't any covariant occurrences of <font face="courier new, monospace">Proxy</font> in the <font face="courier new, monospace">Typeable</font> use-case. So it really doesn't need an explicit <font face="courier new, monospace">Proxy</font> type at all.<div>
<br></div><div>Both the <font face="courier new, monospace">tagged</font> and <font face="courier new, monospace">reflection</font> packages go out of their way to make all contravariant uses agnostic about the proxy type. This rather dramatically cuts down on the amount of ScopedTypeVariable noise I need to use in my code, because I can often just pass a container holding values of the correct type directly as my "Proxy" when I have one.</div>
<div><br></div><div>-Edward<br><br><div class="gmail_quote">On Sat, Jan 26, 2013 at 3:27 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">Very nice idea! Thanks for bringing it up.<br>
<br>
The only case I can see when this "proxyless" approach wouldn't work is<br>
if Proxy ever has to be in a covariant position (e.g. returned by a<br>
function). Then you'd need either a concrete proxy or an existential<br>
wrapper.<br>
<br>
If there are no such functions in the new Data.Typeable (which is very<br>
plausible), then I'd prefer not to include Proxy into base, given that<br>
it's already provided by an alternative package.<br>
<br>
Roman<br>
<br>
* Shachaf Ben-Kiki <<a href="mailto:shachaf@gmail.com">shachaf@gmail.com</a>> [2013-01-25 20:07:10-0800]<br>
<div class="HOEnZb"><div class="h5">> I see that the new-typeable branch in GHC is using "typeRep :: forall a.<br>
> Typeable a => Proxy a -> TypeRep" rather than "typeOf :: forall a. Typeable a<br>
> => a -> TypeRep". This is clearly a big improvement over using undefined<br>
> everywhere.<br>
><br>
> I'd like to suggest a small change, if it hasn't been brought up before --<br>
> "typeRep :: forall proxy a. Typeable a => proxy a -> TypeRep". This makes<br>
> typeRep compatible with any other Proxy type, since it doesn't use any<br>
> properties of the concrete type -- it just uses it to pass information about<br>
> the "a". Things that consume a Proxy don't ever need to refer to Proxy<br>
> explicitly.<br>
><br>
> This would make Typeable compatible with other Proxy libraries, like the one in<br>
> "tagged". It would also make it compatible with any other type of kind * -> *<br>
> -- for example, "typeRep ([] :: [Int])" would be a valid, and arguable more<br>
> convenient, syntax for using typeRep. "Nothing :: Maybe Int" and so on would<br>
> work too. So things that produce a "proxy" don't need to refer to Proxy<br>
> explicitly either.<br>
><br>
> Possibly this would make the Proxy type entirely unnecessary. If it stays,<br>
> though, I suggest that it belongs in a module other than Data.Typeable.Internal<br>
> -- it's a useful type for many other things, and as long as it's in base and<br>
> exposed to users, it might as well be treated as a type in its own right. It's<br>
> also a monad, can provide a variant of `asTypeOf`, and so on.<br>
><br>
> Shachaf<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>
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>
</div></div></blockquote></div><br></div>