[MLton-user] MLton OS.Path under Windows

[Wesley W. Terpstra]

My comments are restricted to MinGW.

On Thu, Nov 13, 2008 at 5:59 PM, Dan DuVarney
<duvarney at reactive-systems.com> wrote:
> I have found that the MLton interpretation of Windows paths breaks a lot
> of code that works under SML/NJ with MinGW. From reading the source
> code, I see that MLton does not consider a path to be absolute unless it
> has both a root and a volume.

I don't believe the code does this. The definition of fromString sets
isAbs=true for "\\bar".

> 1. It differs from the 2002 Basis library standard, which clearly states
> that  both "\\a\\b" and "A:\\a\\b" are absolute paths on Windows (note:
> these strings are SML literals, so double backslash represents a single
> backslash character).

Try it for yourself. Those both set isAbs=true.

> 2. Under MinGW and Cygwin, a rooted path without a volume is not
> ambiguous. The volume and arcs of the root are determined by /etc/fstab.

No. This is a common misunderstanding. Under MinGW /etc (probably)
does not exist. You are being lied to by the msys shell. Write a
program that lists files in /etc to see for yourself that a MinGW
program doesn't see this directory and it only comes from the bash
shell in the msys window. MinGW programs (except for the msys shell)
behave exactly like windows native programs with regards to the
filesystem. There is no unix-like '/'.

So even though MLton complies with the spec and calls "/foo" absolute,
you're not going to convince me that it isn't ambiguous. Write a
program that lists files in "/". Now run it from two different volumes
and see two different results.

> 1. (OS.Path.toString { isAbs = true, vol = "", arcs = ["home", "joe"] })
> raises a Path exception. Shouldn't this return the path "\\home\\joe",
> which would be considered to be a MLton relative path? Or is MLton
> requiring that all absolute paths include a volume?

>From the standard I quote:
> toString: The exception Path is raised if validVolume{isAbs, vol} is false,
> validVolume: Under Microsoft Windows, the valid volume names have the form "a:", "A:", "b:", "B:", etc. and, if isAbs = false, also ""

I agree that the standard sucks because it contradicts itself here.
Earlier it purports that "\\a\\b" isAbs, but now it forbids
isAbs=false + volume="". This directly contradicts that toString o
fromString is the identity, but that claim is wrong anyway since
"foo/bar" -> "foo\bar".

> 2. Similarly, (OS.Path.mkCanonical "\\home\\joe") raises a Path
> exception. Why not simply return the input unchanged?

I think this is a consequence of toString as above.

Anyway, it probably makes sense to allow volume="" and isAbs=true in
defiance of the standard, but we probably need some standard wranglers
to weigh in on the topic first.

I still believe that the standard should've said that "\\foo\\bar" is
not absolute on windows (since it IS ambiguous and depends on your
current directory), but I lost this fight long ago. Instead we have a
standard that says in some places yes and some places no.