[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: PATHNAME-LOGICAL (version 2)


Basically I like this proposal.  We use logical pathnames a lot, and
this proposal would make them even better without appearing to require
any incompatible change for us.

>   The syntax of a logical pathname namestring is as follows:
>      host ":" { directory ";" }* [ name ] [ "." type [ "." version ]]

I would prefer to use "#" as the version prefix.  More than once I've
been annoyed when using Symbolics pathnames to not be able to specify a
version without also specifying the type.

>   A word consists of one to twelve uppercase letters, digits, and hyphens.
>   Lowercase letters are translated to uppercase.  The consequences of using
>   other characters, or more than twelve characters, are unspecified.

The 12-character limit doesn't seem to have any clear significance.
Since it is common for older file systems to have an 8-character limit
for file names, maybe it would be more meaningful to say that names can
be any length, but only the first 8 characters are guaranteed to be
significant on all implementations.

>   There is no device, so the device component of a logical pathname is
>   always :UNSPECIFIC.  No other component can be :UNSPECIFIC.

I presume you mean that the standard doesn't specify any portable
meaning for an :UNSPECIFIC component, and don't intend to rule out its
use in generic pathnames as an extension?

>   DEFINE-LOGICAL-PATHNAME-TRANSLATIONS host translations &key   [Function]
>     Define a logical pathname host named <host> (a string or a symbol which
>     is coerced to a string).  <translations> is a list of translations.
>     Each translation is a list of from-wildcard and to-wildcard.
>     From-wildcard must be a logical pathname or a string coercible to a
>     logical pathname. 

Could we say
  ...  coercible to a logical pathname using "<host>:" as the
  default pathname.
so that the host doesn't have to be explicitly supplied every time?

> 	...	To-wildcard must be a physical pathname or a 
>     coercible to a physical pathname. 

Is there any reason to not permit this to be another logical pathname?

>     There are no keyword arguments specified by this standard, but any
>     implementation extensions are provided as keyword arguments or as
>     translations with more than two elements.

An extension I would like to have is the ability to specify what syntax
will be used for parsing the name strings.  If I'm using logical
pathnames for my own convenience, rather than portability, then I would
like to be able to use whatever pathname syntax I like the most.

> Current practice:

The Explorer also has a comparable logical pathname facility, although
the translation mechanism is unfortunately less general than proposed
here.  The namestring syntax used is slightly different:

  host ":" [{directory "."}* directory ";"] [name] ["." type] ["#" version]

The newest version is indicated by ">" instead of "newest".