Changes to Typeable

[Simon Marlow]

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

Code size?  It might only be a small effect for most code, but we 
occasionally see large files of automatically-generated data declarations.

Also I rather like it that making a new data type is so cheap in terms 
of code size.  A single module containing "data T = A | B":

$ size foo.o
    text    data     bss     dec     hex filename
      91      32       0     123      7b foo.o

If I add "deriving Typeable":

    text    data     bss     dec     hex filename
     587     312       0     899     383 foo.o

7x larger!

Cheers,
	Simon





>
> 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
>