large binaries

[Alastair Reid]

Malcolm Wallace <Malcolm.Wallace@cs.york.ac.uk>:
> For instance, I can find all the following symbols in the binary for
> "hello world" (compiled with nhc98):

>     putStr, shows, showChar, showParen, showString, fromCString,
> toCString, hGetFileName, hPutChar, hPutStr, error, flip, id, init,
> length, not, putChar, putStrLn, seq, show, subtract, exitWith,
> instance Bounded Int (maxBound, minBound), instance Enum Ordering
> (succ, pred, toEnum, fromEnum, enumFrom, enumFromThen, enumFromTo,
> enumFromThenTo), instance Enum ErrNo (succ, pred, toEnum, fromEnum,
> enumFrom, enumFromThen, enumFromTo, enumFromThenTo), instance Monad
> IO (>>=, >>, return, fail), instance Eq ErrNo (==, /=), instance Eq
> Int (==, /=), instance Eq Ordering (==, /=), instance Num Int (+, -,
> *, negate, abs, signum, fromInteger), instance Ord Int (compare, <,
> <=, >=, >, max, min), instance Show ErrNo (show, showsPrec,
> showList), instance Show IOError (show, showsPrec, showList),
> instance Show Int (show, showsPrec, showList)

> [...]

> In fact, most of the extra stuff in "Hello World" is there purely to
> handle all possible error conditions in the I/O monad.

How many of those class methods could actually be executed and how
many are included just because the dictionary that contains them is
included?  And how many of those dictionaries are included just
because they are reachable from the dictionary of a subclass?

Some compilers for C++ and Java are claimed to discard member
functions which cannot possibly be executed even if the corresponding
vtable is kept.  The simplest (least effective) way of doing this is
to discard all enumFromThenTo methods if none of the live code refers
to enumFromThenTo.  More effective is to discard the Int instance of
enumFromThenTo if all enumFromThenTo references can be shown to
involve other types.


--
Alastair Reid                 alastair@reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/