Issue: PATHNAME-LOGICAL (version 2)

["David A. Moon" <Moon@stony-brook.scrc.symbolics.com>]

I might not agree with all of your points here, but I think they
are well-taken.  Do you mind if I forward this message to
CL-Cleanup or do you want to keep it private?

    Date: Thu, 25 May 89 12:38 EDT
    From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>

    1 I believe that mixing in the issue of parsing out host components from
      pathname namestrings is a real mistake -- I hope it it grave enough to
      kill this proposal (of the spirit of which I am otherwise extremely
      supportive.)

      To my thinking, a much better idea would be to define a new function, say,
      (LOGICAL-PATHNAME <host-name> <namestring>) which would return a logical
      pathname.
      This has the advantage of not requiring that CL get into the business
      of deciding whether hosts in general are found by
      "HOST:" or "HOST::" or "/../HOST/" or whatever, and I think that this is
      necessary in order to avoid huge confusion.

      It has the disadvantage of not -specifying- a way for users to type
      a logical pathname on a specific when being prompted by the system
      (ie it doesn't specify the format of the string one must feed into the
      PATHNAME function in order to get out a specific logical pathname.
      It should be noted that CLtL is silent in general on what strings
      produce what results from PATHNAME and I suspect it would be a mistake
      to attempt to change this at this stage -- my extremely positive
      experiences with symbolics' integrated and largely-consistent pathname
      system notwithstanding.)
      Note that -implementations- are free to specify some way of specifying
      logical pathnames -- Symbolics' specification would be that one
      specifies a string with a prefix of "Logical-Host-Name:"

    2 My second problem is with the syntax of the pathnames.
      I really think that this pseudo-ITSism has gone on long enough.
      It has pissed me off for years that bolix logical pathnames don't
      have the same basic syntax as LMFS and FEP pathnames (which after all
      have the best of all possible syntaxes.  I'm not joking!)

      I note the rationale
	``The choice of logical pathname syntax was guided by the goal of being
	  visually distinct from real file systems.''
      but have never bought this argument and never will.  By the same reasoning,
      shouldn't FEP filesystem pathnames be visually distinct from their LMFS
      counterparts?

      The present logical pathname syntax is just too complicated -- it's like
      C code (do I have a use a #\; or a #\. here?) -- and more importantly,
      makes it unnecessarily hard to express `the root directory' and
      `up one directory level' and suchlike.

      Another bug with the existing syntax is that it requires at least one level
      of directory;  this has often annoyed me with lispm logical directories.
      One can't say "PCL:>*.*.*", one must instead use "PCL:>PCL>*.*.*" or somesuch.

	  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.  To-wildcard must be a physical pathname or a string
	    coercible to a physical pathname.  Translations are searched in the
	    order listed, so more specific from-wildcards must precede more general
	    ones.

    3 Because of my point (1) above, I believe that the `left-hand' side of the
      translation must be a string which is coerce to a logical pathname by the
      [proposed] function (LOGICAL-PATHNAME <host-specified-by-first-arg-to-def-l-p-t> <the-string>)
      There are problems with allowing `from-wildcard' to be a logical pathname object:
      firstly, it is an error for it to be a logical pathname with a different logical
      pathname host and secondly there are conceivable circularity problems with
      actually defining or redefining such a form (the pathnames themselves depend
      on the result of evaluating the whole form in some sense.)

      So I'd require your examples to be written as

	  ;A simple, and typical, example
	  (define-logical-pathname-translations "FOO"
	     '((">**>*.*.*" "MY-LISPM:>library>foo>**>")))

	  ;A more complex example
	  (define-logical-pathname-translations "PROG"
	     '((">RELEASED>*.*.*"       "MY-UNIX:/sys/bin/my-prog/")
	       (">RELEASED>*>*.*.*"     "MY-UNIX:/sys/bin/my-prog/*/")
	       (">EXPERIMENTAL>*.*.*"   "MY-UNIX:/usr/Joe/development/prog/")
	       (">EXPERIMENTAL>DOCUMENTATION>*.*.*"
					"MY-VAX:SYS$DISK:[JOE.DOC]")
	       (">EXPERIMENTAL>*>*.*.*" "MY-UNIX:/usr/Joe/development/prog/*/")
	       (">MAIL>**>*.MAIL"       "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))

      with the explicit proviso that the "MY-LISPM:" "MY-UNIX:" etc syntax on the
      right-hand sides is implementation-specific