Changes to Typeable

Ganesh Sittampalam ganesh at earth.li
Thu Oct 4 13:59:29 CEST 2012


I have some nebulous concerns about abstraction violation, but since
Typeable only lets you find out what the structure is, not actually take
apart the contained data, it doesn't seem too much of a problem.


On 04/10/2012 10:44, Simon Peyton-Jones wrote:
> I'm beginning to regret mentioning optimisation -- it's purely an implementation matter.  Yes the same dictionaries get constructed, the runtime behaviour is unchanged. The difference is that when GHC asks "Is type constructor T an instance of Typeable" it would know that the answer is "yes, and the dictionary is called $dfTypeableT".  That's all. Its saves the lookup, and more important, saves the very existence of the table.
> 
> I think it would be better to focus the discussion on the question of whether you would ever NOT want a type constructor to be an instance of Typeable
> 
> S
> 
> | -----Original Message-----
> | From: libraries-bounces at haskell.org [mailto:libraries-
> | bounces at haskell.org] On Behalf Of Andres Löh
> | Sent: 04 October 2012 10:30
> | To: Simon Peyton-Jones
> | Cc: libraries at haskell.org
> | Subject: Re: Changes to Typeable
> | 
> | > So back to the Plan A vs Plan B discussion.
> | 
> | I'm sorry, I don't completely understand why Plan A is an
> | "optimization". As far as I know, the typechecker doesn't merely have
> | the task of answering the question "does Typeable X" hold, but rather it
> | has to come up with evidence that "Typeable X" holds. I fail to see how
> | even the knowledge that every concrete datatype is in principle Typeable
> | makes it any easier to come up with the type representation that's
> | required during run-time.
> | 
> | For example, if you consider
> | 
> | data AnyTypeable = forall a. (Typeable a) => AnyTypeable a
> | 
> | and you unpack and use such a value in a function, then clearly the only
> | place to get the type representation from is the constructor itself, and
> | similarly,
> | 
> | data Any = forall a. Any a
> | 
> | should really not have any type representation available at runtime at
> | all.
> | 
> | Similarly, for less extreme cases, we'd still need dictionary
> | transformers and plug together type representations from different
> | components. So why can we get rid of the instance table? What am I
> | missing?
> | 
> | Cheers,
> |   Andres
> | 
> | --
> | Andres Löh, Haskell Consultant
> | Well-Typed LLP, http://www.well-typed.com
> | 
> | _______________________________________________
> | Libraries mailing list
> | Libraries at haskell.org
> | http://www.haskell.org/mailman/listinfo/libraries
> 
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 




More information about the Libraries mailing list