[MLton] Semantics of giving a .c file to mlton?

[Matthew Fluet]

On Thu, 23 Oct 2008, Ryan Newton wrote:
> Ah, thanks!  That explanation makes sense, but I would not have
> guessed that gcc had such an odd convention (assumes an arbitrary
> return type and continues compiling?!).

The behavior is mandated by the C standard.

> In my situation, I didn't want to have to invoke mlton twice.  (Once
> to generate the header.)  That would be pretty painful (has to
> typecheck the whole app twice -- several extra seconds).

The export header should only depend on the static '_export' expressions 
in your program.  (And the order in which they are type checked, so be 
careful if you rearrange files within .mlb files.)  That is, if you have 
isolated your exported functions into a small number of .sml files, you 
could reasonably do the following in a Makefile:

export.h: export1.sml export2.sml export3.sml
 	mlton -stop tc -export-header export.h prog.mlb

prog: prog.mlb $(shell mlton -stop f prog.mlb) export.h extra.c
 	mlton prog.mlb extra.c

Of course, if you are in a Makefile, then you might as well compile the 
extra.c file by itself:

export.h: export1.sml export2.sml export3.sml
 	mlton -stop tc -export-header export.h prog.mlb

extra.o: export.h extra.c
 	gcc -Wall -c extra.c

prog: prog.mlb $(shell mlton -stop f prog.mlb) extra.o
 	mlton prog.mlb extra.o

> However, one thing I haven't tried is making a single call to mlton,
> with an -export-header flag, AND a .c file that depends on the header.
> Presumably, the ordering is such that this is safe?  This is probably
> what I should be doing.

That should work, since the export header will be written at the end of 
type checking and be there before the .c file is compiled.

-Matthew