[MLton] Main.main idiom

[Stephen Weeks]

> I was recently reminded that I am occasionally bothered by having to
> scatter call-main.sml files around to actually create the side effect that
> runs the program.  It would be nice to allow something like:
> 
>   mlton -mainfn Main.main prog.mlb
> 
> There are a variety of main functions one could have,
> with corresponding code:
...

Are you proposing to do a little type inference to decide how to call
main?  That seems messy.

In any case, I'm not sure if the small gain in brevity is worth the
complexity of another option.

Consider a slightly more general-option

	-suffix <topdec>	suffix topdec to the end of the program

Then one could express each of your examples:

-suffix 'val () = Main.main ()'
-suffix 'val () = OS.Process.exit (Main.main ())'
-suffix 'val () = OS.Process.exit (Main.main (CommandLine.name (),
                                     CommandLine.arguments ()))'

But I think I'd still rather see no option at all.

BTW, I think arguments about portability w.r.t SML/NJ and MoscowML are
also way down in the noise below the many other porting issues.

Another thought.  Why don't we just call "Main.main ()" in the main
program?  Part of the reason for needing a separate file is that we
are using the same code for MLton and SML/NJ, and we don't want SML/NJ
to call main.  However, if we're using the MLton stubs for compiling
with SML/NJ, perhaps we could put the call to main in the main
program, predicated on MLton.isMLton, thus avoiding a separate file
and the option altogether.

Maybe there is a slightly bigger problem to solve that can be solved
without a new option.