[MLton-user] MLton OS.Path under Windows

[Andreas Rossberg]

"Wesley W. Terpstra" <wesley at terpstra.ca> wrote:
>
> 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".

The spec of OS.Path is probably the most inconsistent part of the standard. 
I have a page-long list of issues, including these ones. The definition of 
canonical paths and the treatment of empty arcs are particularly off. Even 
the examples explicitly given contradict the specification (e.g. for cases 
as simple as "/").

However, I think that -- apart from the "bug" about validVolume{isAbs=true, 
vol=""} -- the standard is consistent about treating "absoluteness" and 
presence of volumes independently. Whether that's a useful definition is 
another question. The idea probably was that you want to be able to somehow 
qualify paths like "bla\\bla" and "\\bla\\bla" differently, which is useful 
(under Windows, drives easily get mapped to different letters at different 
times, so you often want to make your paths absolute for a drive, but not 
"too absolute").

The reason that validVolume does not reflect this might simply be an 
oversight - an earlier version of the spec may have had a different 
treatment of volumes.

- Andreas