Changes to Typeable

[Simon Marlow]

On 08/10/2012 13:12, Ivan Lazar Miljenovic wrote:
> 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 :/

The extra time + space would be proportional to the number of data 
types, not the number of constructors.  But it would probably have a big 
effect on compilation time for a module with lots of data types.

Actually we could probably generate a lot less stuff for a derived 
Typeable instance.  Right now we pre-generate both the TypeRep and the 
TyCon, but we could generate them at runtime from the 
(package,module,name) triple instead.

Cheers,
	Simon




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