Typeable

Thu Mar 26 14:50:38 UTC 2015

This is now on Phab as https://phabricator.haskell.org/D757

I'll be making some comments there.

On Mar 26, 2015, at 9:23 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> I'll take a look in the next few days. I'm concerned about that performance regression -- we'll need to get a handle on it.
> 
> Enjoy your holiday!
> 
> Richard
> 
> On Mar 26, 2015, at 8:48 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
>> Iavor, Richard, and others
>> 
>> We always thought it was the Right Thing to generate the runtime representation for a TyCon (used in Typeable type representations) at the definition site of the type, not “on the fly”.  I thought I’d do this.
>> 
>> But it was a LOT harder than I expected.  I have spent a ridiculous amount of time on it over the last three weeks.  Sigh.
>> 
>> However (a) it’s done, (b) I did a lot of other tidying up (as usual).  So I’m keen to use it.  
>> 
>> Would you like to take a look?  It’s on branch wip/T9858-typeable-spj.  Relevant log messages below.
>> 
>> Unsurprisingly, some perf/compiler tests get a bit slower (see below). 
>> 
>> More surprisingly, there are two perf/should_run tests that get worse
>> 
>>    perf/should_run  T5205 [stat not good enough] (normal)
>> 
>>    perf/should_run  lazy-bs-alloc [stat not good enough] (normal)
>> 
>> This is much more surprising: neither seems to have anything much to do with Typeable.  But I can’t investigate before I go on holiday. Would anyone else like to?
>> 
>> It’s all up to date wrt HEAD.
>> 
>> Simon
>> 
>>  
>>  
>> commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8
>> Author: Simon Peyton Jones <simonpj at microsoft.com>
>> Date:   Thu Mar 26 11:06:12 2015 +0000
>>  
>>     Remove a redndant 'return'
>>  
>> commit a6200759fd2f3f0e901cb2092e148bf31abb08b4
>> Author: Simon Peyton Jones <simonpj at microsoft.com>
>> Date:   Mon Mar 23 14:53:53 2015 +0000
>>  
>>     Error message wibbles
>>    
>>     These are associated with
>>      - new instance reporting
>>      - typeable changes in -ddump-simpl output
>>      - -ddump-types being a bit less verbose
>>      - some renaming of type variables in debugger output (no idea why this happens)
>>  
>> commit fe510d911b6cf61d6884b8b42d8771d4aea3229f
>> Author: Simon Peyton Jones <simonpj at microsoft.com>
>> Date:   Mon Mar 23 14:50:23 2015 +0000
>>  
>>     Generate Typeble info at definition sites
>>    
>>     This patch implements the idea floated in #9858, namely that we should
>>     generate type-representation information at the data type declaration
>>     site, rather than when solving a Typeable constraint.
>>    
>>     However, this turned out quite a bit harder than I expected.  I still
>>     think it's the right thing to do, and it's done now, but it was quite
>>     a struggle.
>>    
>>     See particularly
>>       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
>>       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
>>    
>>     The most painful bit was that to generate Typeable instances (ie TyConRepName
>>     bindings) for every TyCon is tricky for types in ghc-prim etc:
>>       - we need to have enough data types around to *define* a TyCon
>>       - many of these types are wired-in
>>    
>>     Also, to minimise the code generated for each data type, I wanted to generate
>>     pure data, not CAFs with unpackCString# stuff floating about.
>>    
>>     Performance
>>     ~~~~~~~~~~~
>>     Three perf/compiler tests start to allocate quite a bit more. This isn't surprising,
>>     because they all allocate zillions of data types, with practically no other code,
>>     esp T1969
>>    
>>        T1969:  GHC allocates 30% more
>>        T5642:  GHC allocates 14% more
>>        T9872d: GHC allocates  5% more
>>    
>>     I'm treating this as acceptable.  The payoff comes in Typeable-heavy code.
>>    
>>     Remaining to do
>>     ~~~~~~~~~~~~~~~
>>     * I think that "TyCon" and "Module" are over-generic names to use for
>>       the runtime type representations used in GHC.Typeable.  Better might
>>       be "TrTyCon" and "TrModule".  But I have not yet done this
>>     
>>     * Add more info the the "TyCon" e.g. source location where it was defined
>>    
>>     * Use the new "Module" type to help with Trac #10068
>>    
>>     * It would be possible to generate TyConRepName (ie Typeable instances)
>>       selectively rather than all the time.  We'd need to persist the information
>>       in interface files.  Lacking a motivating reason I have not done this, but
>>       it would not be difficult.
>>    
>>     Refactoring
>>     ~~~~~~~~~~~
>>     As is so often the case, I ended up refactoring more than I intended.
>>     In particular
>>    
>>     * In TyCon,
>>           - a type *family* (whether type or data)
>>             is repesented by a FamilyTyCon
>>           - a algebraic data type (including data/newtype instances)
>>             is represented by AlgTyCon
>>       This wasn't true before; a data family was represented as
>>       an AlgTyCon.  There are some corresponding changes in IfaceSyn.
>>    
>>       Also get rid of the (unhelpfully named) tyConParent.
>>    
>>     * In TyCon define 'Promoted', isomorphic to Maybe, used when things
>>       are optionally promoted; and use it elsewhere in GHC.
>>    
>>     * Each TyCon, including promoted TyCons, contains its TyConRepName,
>>       if it has one.  This is, in effect, the name of its Typeable
>>       instance.
>>    
>>     * I added PatSynId, DefMethId, and ReflectionId to the IdInfo.IdDetails
>>       type.  They are used for debugging only, namely to suppress excessive
>>       output in -ddump-types.
>>    
>>     * Tidy up the generation of PrelInfo.knownKeyNames
>>    
>>     * Move newImplicitBinder from IfaceEnv to BuildTyCl
>>    
>>     * PrelNames.conName renamed to dcQual for consistency with varQual, tcQual
>>    
>>     * Move mkDefaultMethodIds, mkRecSelBinds from TcTyClsDecls to TcTyDecls
>>  
>> commit 021e6f583a1159b0a3581ab1713d560cadc2bdf7
>> Author: Simon Peyton Jones <simonpj at microsoft.com>
>> Date:   Mon Mar 23 14:32:31 2015 +0000
>>  
>>     tcRnDeclsi can use tcRnSrcDecls
>>    
>>     I'm not sure why tcRnDeclsi didn't call tcRnSrcDecls before, but now it
>>     does.  About 20 lines of code vanish. Hooray.
>>  
>> commit 6473d110ab1aa22a5933e405b59e3f597562ce02
>> Author: Simon Peyton Jones <simonpj at microsoft.com>
>> Date:   Fri Mar 20 12:38:42 2015 +0000
>>  
>>     Implement lookupGlobal in TcEnv, and use it
>>    
>>     This localises the (revolting) initTcForLookup function, exposing
>>     instead the more civilised interface for lookupGlobal
>>  
>> commit 7078a11f50e3af9139dd5ceef032e89047677833
>> Author: Simon Peyton Jones <simonpj at microsoft.com>
>> Date:   Fri Mar 20 12:36:22 2015 +0000
>>  
>>    Comments and white space
>>  
>> commit 48512df5751a07fd503f0ba523e5504d09ee258d
>> Author: Simon Peyton Jones <simonpj at microsoft.com>
>> Date:   Fri Mar 20 12:27:59 2015 +0000
>>  
>>     Improve the error messages for class instance errors
>>    
>>     See Note [Displaying potential instances].
>> simonpj at cam-05-unx:~/code/HEAD-5$
>>  
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150326/2a35de7b/attachment-0001.html>