Re: Inlining errors...

[Josef Sveningsson]

On Wed, 19 Apr 2000, Jan-Willem Maessen wrote:

 I agree so wholeheartedly that I just write a (very!) short paper on
 the subject for ICFP (having discovered to my surprise that no such
 write-up existed).  It describes how to identify such expressions and
 hoist them out so they don't end up getting inlined.  It's still being
 refereed is thus likely to be revised, but if you're interested in a
 pre-print take a look (there are no pointers to it from elsewhere at
 the moment):
 
It's interesting reading. However, it seems to me that it would interact
badly with minimal typing derivations (mtd). Mtd is an algorithm for type
checking which computes the least general type instead of the most
general. This is used by some compilers to guide other optimisations. Some
optimisations, like certain representation analysises, do a better job on
less polymorphic code and therefore it is desirable to have less general
types.

Does ghc use mtd or some other heuristics to remove redundant
polymorphism?

/Josef

PS. Sorry for not having any pointers to mtd.

Inlining errors...

[Jan-Willem Maessen]

George Russell writes:
 Well that's a big question.  As I understand it, the errant value,
 lvl20, is a string representing an error message (which I suppose is to
 be thrown in the event of a matching failure).  Since it should
 only be used on error, surely there is no speed benefit to inlining it,
 and probably there is a space penalty (since you store the string 
 multiple times).  In this case there is a very real disadvantage, since
 inlining forces everything that imports that module to recompile.  So
 my suggestion would be that values required only for errors should never
 be inlined or put in a .hi file.

I agree so wholeheartedly that I just write a (very!) short paper on
the subject for ICFP (having discovered to my surprise that no such
write-up existed).  It describes how to identify such expressions and
hoist them out so they don't end up getting inlined.  It's still being
refereed is thus likely to be revised, but if you're interested in a
pre-print take a look (there are no pointers to it from elsewhere at
the moment):

@unpublished{bottomExtract,
  AUTHOR   = {Jan-Willem Maessen},
  YEAR = {1999},
  month= Mar,
  TITLE= {Bottom Extraction: Factoring error handling out of
  functional programs},
  documentURL  = "http://www.csg.lcs.mit.edu/~earwig/extraction.ps"
  note = {Submitted to ICFP 2000}
}

-Jan-Willem Maessen