[MLton-user] MLton OS.Path under Windows

[Dan DuVarney]

Greetings:

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'm inclined to think this is a mistake
for the following reasons:

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).

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.

Furthermore, I am observing behavior under SVN r6941 MLton/MinGW32:

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?

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

On a positive note, except for this path handling issue, all the code I
have thrown at MLton so far is compiling and running. I would appreciate
some clarification on whether the current OS.Path behavior is considered
to be correct as-is, or is likely to change in the near future, so that
I can decide how to handle paths in an implementation-independent fashion.

Thanks,


-Dan

-- 
Dan DuVarney
Senior Software Engineer         Reactive Systems Inc.
duvarney at reactive-systems.com    +1 (919) 324-3507 ext. 103
OpenPGP (GnuPG) public key file:
http://www.reactive-systems.com/~duvarney/pgp_public_key.txt