HEADS UP: interface file change, you may need to clean

[Manuel M T Chakravarty]

Thanks, Max. The old set up has been annoying me in the past :)

Manuel


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,
> 
> Max
> 
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc