Re: [Sml-implementers] compilation management

[Doug C. <e...@fl...>]

At 10:14 PM +0100 10/6/01, Dave Berry wrote:
>[...] As a concrete proposal,
>suppose that files had to use the following character set:
>[a-zA-Z0-9_+.-], they had to be case-insensitive, and directories were
>indicated with forward slashes.  This would be portable across all versions
>of Windows (including CE, and including both FAT and NTFS), all versions of
>Unix/Linux, and (I think) MacOS.  Projects might not port to OS's that
>limit the length of file names beyond the user's choice of names, or OS's
>that have other limitations; in these cases users would have to rewrite the
>file names.  So this achieves a level of portability that is pragmatically
>useful, and is never worse than the alternative.

This would work well with MacOS. Pathname and arc length limitations 
are an area where guidance to the user should be provided, and 
perhaps warnings issued by the compilation manager, to foster 
portability. For example, MacOS (version <= 9) limits path lengths to 
255 (or 511) characters, and arcs to 32 characters. Other file system 
may not like '.' used arbitrarily in file names. MacOS doesn't care.

At 2:42 PM +0200 10/8/01, Andreas Rossberg wrote:
>Why not adopt an existing standard and use (a subset of) URI path
>syntax? It is well-known, more or less system independent, and
>expressive enough - and pleasently close to Unix syntax. Every OS
>already has conventions to map it down to native paths.

It is nice that URI provides a means for specifying both relative and 
absolute paths, including syntax for climbing a relative path 
hierarchy. The difficulty, of course, is defining a reasonable 
subset, since many kinds of non-portable path and file names can be 
written with URI.

Dave Berry's character set and case-insensitivity, augmented with 
URI's relative path traversal, is about right. Add arc length 
limitations, and we'd have a very portable syntax.

e