HEADS UP: interface file change, you may need to clean
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Fri Feb 24 00:43:17 CET 2012
Thanks, Max. The old set up has been annoying me in the past :)
Max Bolingbroke <batterseapower at hotmail.com>:
> On 22 February 2012 20:44, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
>> Thanks Max. That sounds useful. But can you just remind us what the simplification is? Presumably it was complicated in the first place for a reason?
> Previously IfaceTyCon was an algebraic data type with cases for Bool
> TyCons, Int TyCons, the Any tycons and various other wired-in TyCons.
> Most TyCons were represented as in IfaceTc which just contained an
> IfExtName. The special cases were necessary in order to serialize
> these TyCons correctly - particularly in the case of e.g. the Any
> tycon and the tuple tycon.
> However, in that earlier patch I made a change to how names were
> serialized so that the wired-in names of tuples can be serialized and
> deserialized as a simple word without losing any information. This
> change was forced as a result of having to add support for another
> kind of tuple (constraint tuples). As a result the IfaceTyCon data
> type no longer had to special case tuples, but it still had to
> special-case the Any TyCons because all of the Any TyCons have the
> same name even if they have different kinds, so my smart code for
> serializing wired-in names wasn't sufficient to remove that case.
> With polymorphic kinds the Any TyCon can be given a single name so
> this special case is also unnecessary, and IfaceTyCon can become a
> simple newtype over an IfExtName.
> The other advantage of special-casing some TyCons in IfaceTyCon was
> that some "common" TyCons can be given a special serialized
> representation, saving some space, but I found that removing these
> special cases barely made any difference to interface file sizes (IIRC
> it was on the order of a percent or less) so there really was no
> reason to keep them around.
> Hope that helps,
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
More information about the Cvs-ghc