[plt-scheme] 299.202

MzScheme and MrEd are now version 299.202 in the SVN repository trunk.

The main changes are in path handling under Windows. Some examples:

 * \\?\ paths are supported.

 * If X is an element in the list returned by `(directory-list D)' for
   some directory path D, then `(build-path D X)' refers to the file
   X in directory D.

   Obviously, this should be the case. Consider, though, what happens
   when the name of the file returned by `directory-list' is "aux" or
   "com1". Naive handling of the path would leave you with something
   that ends in "aux" or "com1", which refers to the AUX or COM1
   device, not a file at all. Or suppose that the file name ends in
   spaces and/or periods; then the spaces or periods would normally be
   stripped away. The key to accessing the file is to build a \\?\
   path, and MzScheme now does that for you.

 * If X refers to a child of directory D, then the first argument of
   `split-path' refers to directory D and the second result refers to
   the child.

   Again, this seems trivially right, but it's not trivial to
   implement. Consider, for example, "C:/x /y", which refers to "y" in
   directory "x " (note the space). A naive splitting produces "C:/x /",
   whose trailing space doesn't count. Here, again, the solution
   involves \\?\ paths.

   Consider also the case \\?\C:\x., which refers to a file or
   directory "x." on drive "C". Windows has no standard syntax for
   naming the file "x." relative to its directory, so I had to invent
   one for MzScheme: \\?\REL\\x.. The \\?\REL\\ prefix is removed in
   the printed form of the path (including the result of
   `path->string'), so string-based comparisons work as expected. Note
   that when you write such paths as a Scheme string, you need lots of
   escaping backslashes: "\\\\?\\REL\\\\x.".

   Throw in UNC paths and you get a few more cases to disambiguate.

Those with a strong stomach and an unhealthy interest in Windows path
parsing should see the new last chapter of the MzScheme manual. It
describes the parsing of Windows pathnames. The design goals for
MzScheme were to make things work right (as in the last two bullets
above) and to interpret paths in the same way as the OS. The latter of
these goals is particularly tricky; much of the new chapter is just
documenting the OS's arbitrary rules, which don't seem to be documented
anywhere else. Overall, the solution in MzScheme is unsatisfying and a
bit embarrassing, but it's still an improvement.

Other changes:

 * `read-syntax' adds a 'paren-shape property to pairs and vectors 
   parsed from [], {}, #[], and #{}.

   A revised Slideshow "code.ss" will use this information to format
   code with [] and {}.

 * Inside MzScheme: added scheme_get_port_file_descriptor()
   and scheme_get_port_socket().


Matthew