Correct type of fromRep, description of use

fromRep actually returns an option type, as described in issue #65 the modified specification isn't always correct but the discussion there indicates this is actually the intended behavior.
Merge pull request #67 from robsimmons/patch-1

Correct type and description of MLton.IntInf.fromRep.
Add even-odd benchmark.

Add a new even-odd benchmark that exercises mutual tail recursion.
Note that it is important that both "even" and "odd" are called from
the main program; if only "even" is called, then the Contify
optimization will move both "even'" and "odd'" to their one return
point and turn the tail recursion into a local loop.
Update benchmark iteration counts.

Increase the benchmark iteration counts so that all benchmarks run for
at least 15 seconds (for amd64-linux on an "Intel(R) Core(TM) i5-3570K
CPU @ 3.40GHz").

Added an "update-counts.sh" script to calculate appropriate benchmark
iteration counts.

Ideally, the benchmark iteration counts should be loaded dynamically
at the time the benchmark suite is executed (rather than being
hard-coded into the benchmark suite executable).  Then, it would be
easier to calibrate appropriate benchmark iteration counts for
different machines.
Generate uniquely named benchmark files for each compiler.

Generate a unique .sml file for each benchmark for each compiler
(derived from the benchmark name and compiler abbreviation).  In
particular, allows running the benchmark suite with "-keep {ssa,g}"
flags for mlton without later compilers overwriting the output from
earlier compilers.
Consistent abbreviations for MLKit and Moscow ML.
Proper benchmark output for repeated '-mlton' arguments.

The code to display the benchmark output would index the benchmark
data by the "compiler" field (which, for "-mlton" arguments,
corresponds to the command line).  A benchmark test with multiple,
identical "-mlton" arguments (for example, to check run-time variance)
would generate distinct benchmark data, but improperly display the
benchmark data.

Instead, index the benchmark data by the "abbrv" field (which, even
for identical "-mlton" arguments, will be distinct).
Update benchmark iteration counts.

Increase the benchmark iteration counts so that all benchmarks run for
at least 30 seconds (for amd64-linux on an "Intel(R) Core(TM) i5-3570K
CPU @ 3.40GHz").
Merge pull request #70 from MatthewFluet/benchmark-infrastructure

Updates to benchmark infrastructure.

Highlights:
 * Add `even-odd.sml` benchmark that exercises mutual tail recursion.
 * Add `update-counts.sh` script to calculate appropriate benchmark iteration counts and update benchmark iteration counts so that all benchmarks run for at least 30 seconds.
 * Updates to benchmark driver program.
Use GNU time in update-counts.sh script.
Update to update-counts.sh script.

Consolidate timing of benchmark programs by simulating a do-while
loop in Bash.
Update to update-counts.sh script.

Report when benchmark program terminates with an error.
Update hamlet.sml benchmark program.

Close the input file after each loop to avoid "SysErr: Too many open
files".
Update fft.sml benchmark program.

The 'test' function raises "Subscript" with a non-power-of-2 argument.
Update model-elimination.sml benchmark program.

Iterate 'main ()' according to 'doit' size parameter.
Update benchmark iteration counts.

Increase the benchmark iteration counts so that all benchmarks run for
at least 30 seconds (for amd64-linux on an "Intel(R) Core(TM) i5-3570K
CPU @ 3.40GHz").
Ignore uniquely named benchmark files.
Refactor sequences

Primitive sequences are indexed by SeqIndex.int, normal sequences
are indexed by Int.int. Introduces primitive sequences earlier on in the
dependency chain.

Changes also make the Span exception more primitive, exposes the unfold
function for arrays and vectors further, and reorder the sequence interface
so that sequence0.sig/sequence.sig and slice0.sig/slice.sig can be read as
parallel corpuses.
Merge branch 'master' into refactor-arrays
Update MLtonVector.adoc

Update unfoldi to be correct and make sense from a type perspective