Changes to Typeable
marlowsd at gmail.com
Mon Oct 8 14:44:05 CEST 2012
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.
>>> | -----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
>> Libraries mailing list
>> Libraries at haskell.org
More information about the Libraries