mkCoreConApps vs. mkConApp

[Simon Peyton Jones]

mkConApp assumes the let/app invariant holds, and hence does not need to carry around, decompose, or test the function type.  Hence slightly more efficient.

My instinct is to make mkConApp have ASSERT checks for the let/app invariant (and indeed the function having enough (->) arrows), but under #ifdef DEBUG.  And rename it "mkLazyConApp" to stress that there's an invariant involved. 

In contrast mkCoreConApp must carry round the types in order to generate a Case sometimes.

Do you feel like doing that?  (In HEAD.)  Or shall I?

Simon

|  -----Original Message-----
|  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
|  Sent: 29 September 2014 20:05
|  To: Simon Peyton Jones
|  Subject: mkCoreConApps vs. mkConApp
|  
|  Hi Simon,
|  
|  I ran into a core-lint error on my branch which led me to wonder: when
|  should anyone use CoreSyn.mkConApp instead of MkCore.mkCoreConApps?
|  They appear to do roughly the same thing, but mkCoreConApps does more
|  checks (specifically, in my case, the let/app invariant check) and
|  claims to be more efficient. mkConApp even tells you to use
|  mkCoreConApps "if possible". When isn't this possible?
|  
|  To fix my error, I changed all uses of mkConApp in MkCore to
|  mkCoreConApps. Problem solved. But it's all a bit of a mystery why the
|  problem was there to begin with. Can you shed any light?
|  
|  Thanks!
|  Richard
|  
|  PS: The reason this happened on my branch is because of different
|  handling of making unboxed tuples, thanks to levity-polymorphism.