[plt-scheme] 352.8

From: Jens Axel Søgaard (jensaxel at soegaard.net)
Date: Sun Oct 22 04:50:12 EDT 2006

Matthew Flatt skrev:
> At Fri, 20 Oct 2006 23:53:09 +0200, Jens Axel Søgaard wrote:
>> It would however
>> be nice to have string->windows-path and string->unix-path
>> so that one can work with Windows paths on Unix and
>> vice versa.
> 
> I can imagine extending the "path" datatype so that it has a kind:
> 'unix, 'macosx, or 'windows. (There's no difference between 'unix and
> 'macosx paths, but kinds should probably stay in sync with the results
> of `system-type'.)
> 
> Then some procedures, like `split-path', could work on all kinds of
> paths, while other procedures, like `open-input-file' require a path
> for the current platform.

That sounds like nice solution.

> This change would expose all of the useful path-processing
> functionality in MzScheme's source code, while pushing into other
> libraries the question of how roots and path elements should be related
> across platforms. 


> For example, it's not clear what to use under Unix
> for the Windows root "C:\\" or "\\\\machine\\volume" or
> "\\?\#^%$#^@\\\\", 

Can't they just stay Windows paths? Manipulations like build-path
and split-paths can be used to tear old Windows paths apart, and
put new ones together - they can then later on be used on a
Windows machine? On a Unix-machine open-input-file on could
raise an exception, when called with a non-convertible
Windows path.

> what to use under Windows for the Unix root "~", or

Then natural choice would be to use the Windows home directory,
but this could quikly lead to a new Cygwin implementation :-)

> what to do with a Unix path element like "a\\b" or a Windows path
> element "a/b".

How about a parameter convert-seperators-in-paths which when true
converts between \\ and /, and if false doesn't? The default
being true, since that is probably most needed?

-- 
Jens Axel Søgaard



Posted on the users mailing list.