Re: [Sml-implementers] compilation management

[Matthias B. <bl...@re...>]

Dave Berry wrote:
> 
> At 10:10 21/09/2001, Matthias Blume wrote:
> >> We could even go so far as to require that no files
> >> in a given library should be case-insensitive-equal. ...
> >
> >This I wouldn't do -- not as a requirement that we burn into a language
> >spec.  The main reason for my saying this is that we should not have to care
> >about such OS- and filesys-specifics at all.
> 
> One thing to consider is whether to provide any support for directories in
> the file paths.  If so, then either we need a convention for directory
> syntax, or people may have to rewrite their project files when they move
> between OSs.  (Although I believe Windows now recognises Unix-style
> directory syntax -- i.e forward slash).  If we do adopt such a convention,
> then we are already part way to limiting the names that can appear.

All this these suggestions and more are fine, but I still think that we should
not burn them into any "standard" (even though we are no longer permitted to
use the word "standard" :-).

My suggestion would be the following 3-point plan:

1. Define a library specification format where file names are coded as generic
   strings, accommodating any possible OS- and implementation-specific name.

   I am actually working on the above.  Please, have patience for a few more days
   until I am ready to unveil my creation. :)

2. Specify a portable pathname syntax, perhaps only for relative pathnames (but
   including the possibility of subdirectories and perhaps even "parent" arcs etc.)
   A library description as I am currently designing it will abstract over a "context"
   relative to which such pathnames are to be interpreted.

   My personal preference for "portable" syntax is Unix-style.

3. Provide an escape hatch from portable pathname syntax to "native" syntax for those
   who don't care about portability for one reason or another.

So the point is that the specification language itself will be neutral to pathname
conventions, but there will be strict guidelines that anyone should follow who
wishes to create portable libraries.

> Possibly the most annoying effect of this limitation would be on people who
> want to write filenames in an non-English language.  But they already have
> to write all their identifiers in ASCII.

Two answers to this:

A. The "portable" syntax from above (point 2.) could and perhaps should allow for
   UTF-8 characters.  (The software that will be processing these names does not
   care about the Unicode-semantics of individual characters with the exception
   of the arc separator '/' and possibly parent- and current arcs (".." and ".").)

B. I wish we could write identifiers using UTF-8 as well. :-)

-- 
-Matthias