[MLton] Windows ports and paths

[Stephen Weeks]

> > I've prepared a hand-made 3-way diff which  ...
> 
> This new patch makes a few changes resulting from Andreas's comments.

OK.  I've checked in this latest patch.  I then went on to do some
cleanup and reformatting.  More importantly, I don't agree with your
change to isArc, which allows "/" in arcs.  I saw your comment
explaining the change and quoting part of the spec.

  (* MLton previously rejected "foo/bar" as an arc.
   * Reading the standard shows that this is NOT a problem.
   * What is more of a problem would be having a null in a filename!
   * Under windows, a ":" may also not be in a filename.
   * 
   * See toString: "provided no exception is raised and none of the strings
   * in arcs contains an embedded arc separator character" -- this means
   * that containing an embedded arc separator character does NOT raise an
   * exception.
   *)

I don't think you're interpreting the spec correctly.  See just above
your quoted region where the spec says

  The exception InvalidArc is raised if any component in arcs is not a
  valid representation of an arc.

Earlier, the spec says

  a non-empty string a corresponds to valid representation of an arc
  only if fromString a returns {isAbs=false, vol="", arcs=[a]}.

I think this makes it clear that "/" should not be allowed in an arc.
This was a recently fixed bug -- see the thread starting at

  http://mlton.org/pipermail/mlton/2005-February/026785.html

In any case, I've gone back to the old (i.e. February) definition of
isArc.