Changes to Typeable

[Simon Peyton-Jones]

Right. Re the library packages that have to change, I replied (4 Oct) thus
It's tiresome, but for good reasons.  You have to talk to each of the maintainers of the other repos, and ask them to implement a patch, which you'll supply.  The patch will probably have
     #ifdef __GLASGOW_HASKELL__ >= 7.7
so that it'll still work with older versions of the compiler. To give them the background you'll probably want to update the wiki page describing the design and its benefits.

However, you are right that if Typeable is always derived for all types, then maybe we can get away with no changes in those packages, which would be good.

7.8: Any uses of "deriving Typeable" would give rise to a warning saying that it is no longer
necessary. Any instances of Typeable would give rise to a warning saying that this code
is being ignored, and replaced by an internal Typeable instance. Packages might break,
or change runtime behaviour due to this change.

Yes, that looks right.  Actually I think it's extremely unlikely that anything would break unless there is something Extremely Naughty happening.

I say, go for it.  Any objections?  Would you be willing to do that Pedro?  Thanks!

Simon

From: josepedromagalhaes at gmail.com [mailto:josepedromagalhaes at gmail.com] On Behalf Of José Pedro Magalhães
Sent: 29 October 2012 09:06
To: Gábor Lehel; Simon Peyton-Jones; libraries at haskell.org
Subject: Re: Changes to Typeable

Sorry, I got a bit lost in this discussion. Let me try to provide a summary.

Current status: I have a local branch with the new poly-kinded Typeable working fine.
It works as described in [1]. It actually allows deriving Typeable for things involving
the Constraint kind, but this can be easily disabled. Either way, I think most of this
is necessary for whatever might follow next. But I'm not sure of how to push the changes,
because I had to make some changes to these repos: array, containers, dph,
template-haskell, and vector. Worse, I also had to change time, which gets built from
a tarball. It might not be worth contacting the authors of these packages for changes
if we're still going to get rid of "deriving Typeable" altogether, so I've been holding this
back.

It's been proposed to remove the possibility to derive Typeable or write instances for it.
I'm supposing the way that this would be implemented would be:

7.8: Any uses of "deriving Typeable" would give rise to a warning saying that it is no longer
necessary. Any instances of Typeable would give rise to a warning saying that this code
is being ignored, and replaced by an internal Typeable instance. Packages might break,
or change runtime behaviour due to this change.

7.10: Explicit uses of "deriving Typeable" or instances are an error.

Regarding split :: (a ~ f i) => Dict (Typeable f, Typeable i), I'm not sure I can judge how
much work that would be. But let's first try to draft a plan for removing Typeable definitions
from the user, and then consider more extensions.


Cheers,
Pedro

[1] http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable
On Tue, Oct 16, 2012 at 8:32 AM, Emil Axelsson <emax at chalmers.se<mailto:emax at chalmers.se>> wrote:
2012-10-15 23:50, Gábor Lehel skrev:

On Mon, Oct 15, 2012 at 7:58 AM, Emil Axelsson <emax at chalmers.se<mailto:emax at chalmers.se>> wrote:

I have a use case:


http://hackage.haskell.org/packages/archive/syntactic/1.3/doc/html/Data-DynamicAlt.html

This is a reimplementation of Data.Dynamic to support casting type `a` to
`Dynamic` given a constraint `Typeable (a -> b)`:

   toDyn :: Typeable (a -> b) => P (a -> b) -> a -> Dynamic

With your suggestion, it seems I should be able to use the ordinary
Data.Dynamic instead.

/ Emil

Great! Do you like my plan? Or perhaps know of a better one?

(Relatedly, *does* this have to go through a separate libraries
process? Or are we considering Typeable as getting completely
replaced, and everything pertaining to it gets discussed here?)

Your plan certainly seems general enough! But I'm afraid I can't really speak about the implications on libraries etc.

/ Emil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121029/321f4955/attachment-0001.htm>