Changes to Typeable

[Ivan Lazar Miljenovic]

On 8 October 2012 22:27, Simon Marlow <marlowsd at gmail.com> wrote:
> 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!

I assume this would affect compilation time as well?  I have code
containing data types containing large number of constructors (biggest
case has 150+) that takes long enough to compile as is :/

>
> 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
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com