[MLton] Cygwin->Mingw32: patch + future

[Stephen Weeks]

> I built a cygwin->mingw32 mlton cross-compiler last night, and it
> works!

This is good to hear.  It would be nice to see the MLton MinGW port
get finished.

> There were only two issues:
> 1. With gcc-3.4, the '-b <arch>' must be the first argument.
> 2. When using cygwin to compile native windows applications via their
> included mingw compiler, the option to use is '-mno-cygwin' instead.
> (I don't know why they did this, but there you have it)

OK.  I've included your patch.

One thing I did change was the condition for using -mno-cygwin.  It is
now

  Cygwin = MLton.Platform.OS.host
  andalso String.hasSubstring (s, {substring = "mingw"})

Testing for "mingw" instead of "i686-pc-mingw" is a bit more general
and hopefully still OK.

> In general, I think most of the CC-controlling options should be
> moved into a config file somewhere. 

As Matthew pointed out, most of them are outside the binary.  And as
you pointed out, not all of them are.  Unfortunately, I don't see an
easy way to move the remaining ones out.

> Some people might want to use 'icc' for example, or under windows
> one of those other non-free compilers.

Once these start getting used, maybe there will be more of a push to
improve the situation.

> I propose to add in MLTON_PROCESS (or maybe MLTON_CHILD?):

I like your proposal.  Adding your stuff to MLTON_PROCESS seems fine.
I have some minor points/questions.

* What is the NULL iosource for?

* What is RedirectionFailure for?

* It seems like you missed the ability to pass the three iosources
(stdin, stdout, stderr) to create.

* I propose to strengthen the use of phantom types.  Right now, all
they do is prevent is turning the same file descriptor into both a
binary and a text stream when using {bin,text}Std{err,in,out}Of.  We
can use them to express whether or not the stream can be extracted.
Once we do that, we can also drop the option return type.

* I wonder if it makes sense to change the semantics from how the
Unix module behaves so that, e.g., two calls to textStdinOf return the
same stream instead of creating a new one (which has no reasonable
behavior).

* I don't think the "Of" suffix does anything.  I propose to drop it.

* For future reference, here's the Microsoft docs that I looked at for
CreateProcess.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/startupinfo_str.asp

Here's a MLtonization of your signature, with my proposed changes.

----------------------------------------------------------------------
signature MLTON_PROCESS =
   sig
      (* Phantom types to keep track of whether a process's IO source is a pipe
       * and hence whether we can extract a corresponding stream.
       * Also keep track of the stream's type (bin or text)
       *)
      type bin
      type text
      type 'a isPipe
      type 'a isNotPipe
	 
      structure Source:
	 sig
	    type 'a t

	    val file: string -> 'a isNotPipe t
	    val inherit: 'a isNotPipe t
	    val lie: 'a isNotPipe t -> 'a isPipe t
	    val null: 'a isNotPipe t
	    val pipe: 'a isPipe t
	 end

      type ('stdin, 'stdout, 'stderr) t

      val binStderr: ('a, 'b, bin isPipe) t -> BinIO.outstream
      val binStdin: (bin isPipe, 'b, 'c) t -> BinIO.instream
      val binStdout: ('a, bin isPipe, 'c) t -> BinIO.outstream
      val create:
	 {args: string list,
	  command: string,
	  (* env = NONE means use the parent environment. *)
	  env: string list option,
	  searchPath: bool,
	  stderr: 'stderr Source.t,
	  stdin: 'stdin Source.t,
	  stdout: 'stdout Source.t}
	 -> ('stdin, 'stdout, 'stderr) t
      val kill: ('a, 'b, 'c) t -> unit
      val reap: ('a, 'b, 'c) t -> OS.Process.status
      val textStderr: ('a, 'b, text isPipe) t -> TextIO.outstream
      val textStdin: (text isPipe, 'b, 'c) t -> TextIO.instream
      val textStdout: ('a, text isPipe, 'c) t -> TextIO.outstream
   end
----------------------------------------------------------------------

> This interface could then be used to implement Unix.* and the
> corresponding Windows.* methods. Also, by using the
> mlton_create_process syscall, there would no longer be a need for
> the spawn syscall. I would remove it in favour of the more powerful
> syscall and change the spawn code to use it instead.

Sounds good.

> The MLTON_PROCESS/CHILD implementation would be conditioned on Platform.OS
> like spawn is now. (ie: use mlton_create_process or fork/exec)

Also good.

> Is anyone working on providing Windows : WINDOWS? (should i?)

I don't know of anyone who is.  We'd be happy to have you working on
it.

> Has the "path handling to get CM files to build properly" been fixed?

No.