On 8 October 2012 22:27, 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!
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@haskell.org [mailto:libraries- | bounces@haskell.org] On Behalf Of Andres Löh | Sent: 04 October 2012 10:30 | To: Simon Peyton-Jones | Cc: libraries@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@haskell.org | http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com