And :newest really returns the file without appended version info.

* (probe-file (make-pathname :name "test" :type "lisp" :version :newest))
#p"/usr/home/blitz/src/test.lisp"

To make a file older just copy it with version+1? But what about other
versions of the file? Do you manually have to copy them?

[...]

I hope you do not mean me, as I had never known those things. I came
from DOS about 10 years ago.

(with-open-file (str (make-pathname :directory '(:absolute "tmp")
                                    :name "foo"
                                    :type "bar"))
  (read-line str))

What is he supposed to think?  ``What?  I am actually supposed
to write that much where "/tmp/foo.bar" works just as well?
Well, ok, at least it's portable.''  Then he reads on, reads
about lots of things in the pathname structure, many of which
are implementation defined, wonders about what a host is (does
Lisp do gethostbyname?  How does it get the files?  By scp?  By
ftp?)  and when he reaches the part about logical pathnames he
is already so confused that he concludes that all this must be
so abstract that he isn't able to understand, let alone use,
any of it.

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

And I don't think I've ever seen there be more than one version of a
file in use.  The tool "mkisofs" commonly used on Unixes to generate
these has a telling bit of code:

   sprintf( newname, "%s%c%c%c%s%s",
           rootname,
           (d1 <=9 ? '0' + d1 : d1 + 'A' - 10),
           (d2 <=9 ? '0' + d2 : d2 + 'A' - 10),
           (d3 <=9 ? '0' + d3 : d3 + 'A' - 10),
           extname,
           ((s_entry->isorec.flags[0] & ISO_DIRECTORY) ||
              omit_version_number ? "" : ";1"));

The upshot of this is that all files written have version ";1", which
makes the numbering rather uninteresting...

In this episode:
- - Lisp is probably the language of the Elves :-);
- - Mordor is in Washington State;
- - Windows is the OS of the Orcs, whilst Unix is the OS of the Men,
  and the others get trampled between them

At some point the metaphors probably get mixed...

[...]

I hope this gets me started. I will try to figure out the
rest. Try&error is mostly the most effective learning method.

Thanks.

And Kent. Don't mind. I understand the problem of explaining the
"obviuos" everytime I try to convince some people of some mathematical
facts. :)

    Julian> * (probe-file (make-pathname :name "test" :type "lisp" :version 1))        
    Julian> #p"/usr/home/blitz/src/test.lisp.1"

    Julian> What's this useable for I cannot imagine, because of :newest not working.

FWIW, the latest sources and the soon-to-be released 18d version of
CMUCL will say:

* (make-pathname :name "test" :type "lisp" :version :newest)
#p"test.lisp"

* (make-pathname :name "test" :type "lisp" :version 1)
#p"test.lisp.~1~"

That is, versions will look like Emacs-style backup file versions.

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

I'm still not entirely clear on the motivation for this
requirement; certainly, it's not clear to me what to do to workaround
this when dealing with files such as libX11.so or the like, except for
setting up a dedicated translation for those.

Someone tell me what I'm doing wrong, please :)

I can't work out where to attach this article, this is probably not
the right place.  Anyway.

One thing I discovered about pathnames and logical pathnames when
trying to be portable is that it is often better not to try and create
pathnames from whole cloth, because there is a little too much
variability between filesystem types and implementations.  Instead if
you start by parsing some namestring, and work from there you often
just don't have to worry about all the details of whether a DOS drive
letter is in the host or the device and so on.  In the great majority
of the cases I have to deal with what I'm trying to do is things like
`given this file, construct a filename in a subdirectory x of its
directory' or (more complex) `given this file and this other file
construct a relative pathname for the first file to refer to the
second'.  Most or all of this is manipulations on directory, name and
type, and the rest of the information you just don't need to care
about.

Cheers

Logical hosts and logical pathnames are a least common denominator solution.
Not all hosts have an upper/lower distinction, so logical hosts deliberately
map all case to upper, just as symbols nil and NIL are mapped to symbol NIL.
In the case of symbols, there is a mapping to the non-obvious case from
|nil| but there none such in logical pathnames because that would be allowing
you to introduce a non-portability.

The purpose of the PATHNAME datatype is to allow you a way to refer to
basically all pathnames in a more or less portable way.  THat is, this
datatype seeks to allow you to manipulate program data, including filenames
that might not be portable.

It may or may not be obvious, but the actual text of ANSI CL actually
began with the text of CLTL and was modified from that; it was not
written from scratch.  This approach to creating the document was a
more or less an explicit decision of the committee, to insure that
there was always an intact document which was believed to be true to
the extent that resources allowed at any time during the process.
That document was massaged through votes and other numerous
"non-technical" edits by Kathy and later by me, until it had changed a
great deal.  But sometimes either confusions of CLTL showed through or
the harshness of bad merging of CLTL with voted changes existed.  In
the case of pathnames, it was both, and it desperately needed
untangling.  I was pretty sure that if we'd had the resources to
untangle it, we'd ALSO have needed to vote some of the things to be
changed once it was more apparent that things didn't agree internally
and/or weren't explained or motivated right and/or just didn't make
sense.

But, poof, the time ran out just as I was due to make another
untangling pass over it and that decision to always have an intact
document we could just run with came into play, and you get what you
could get.

(As a side note, since some people do worry about such things, Steele
was asked to and did verify for purposes of copyright that at the end,
so little remained of the original text that he didn't feel it any longer
infringed or should be considered a derivative work since very little of
the original work remained.)

So the spec is textually lousy for sure in this chapter.  And I'm
sensitive about that... but then again, some people look at the
problems and think "if only I had more words, I'd know more".  Maybe
that's so.  I personally think that if I'd had more time to rewrite
the chapter, it would only have become more obvious that there are
some internal design errors here that needed technical votes to
repair.  I personally think people snag on these design glitches,
_thinking_ they are not understanding something, but in fact just not
seeing tht the design is not as good as it could have been.  I
personally think that although they think they want doc fixes, they
really want technical fixes, or technical changes to a different
paradigm.  But that's just a guess.

Maybe when people say they want a tutorial they mean, a way to walk
the minefield.  That certainly would have been inappropriate to ANSI
CL, because it would have internally suggested that the design was
wrong in places.  And I don't think the committee thought that.

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

FWIW, I found that explanation really useful.  I would suggest one
improvement: be explicit about the fact that colons, semicolons, and
periods have semantic significance in logical pathnames, and what it is,
e.g. "The logical host is separated from the rest of the logical pathname
by a colon.  In fact, this is how logical pathnames are distinguished from
non-logical pathnames, except on Macintoshes, where colons are used as
directory delimiters, resulting in much confusion."  etc. etc.

The followup questions, if you tell me that you believe it is a valid
namestring as is (if it's not, you can of course disregard the rest of
this) are

(i) is the directory component :relative or :absolute?  My guess would
     have been :absolute, but that seems inconsistent with your quoted
     paragraph above

(ii) if :relative, how does one write the namestring for a relative
     LPN with absolute directory?

(iii) if "FOO1;BAR1;" is an LPN namestring with an absolute directory,
     presumably "FOO1;" is also absolute.  What about "BAZ.LISP" -
     does it have no directory, or (:absolute) as a directory?  Is
     there a case for writing ";BAZ.LISP" when I want to make sure
     that a later merge-pathnames will take the directory component
     from its second argument?

-dan

--

  Heh.  This is probably true, but it takes a lot of work to find the way
  back to how you found something out.  Most of us discover something in a
  round-about way if we have not learned it from someone else.

| Good teachers remember what it was like not to know, and they remember
| how they got from there to knowing.

  However, this can be their most serious problem in teaching others.
  Spending years and years on something until it finally makes sense is not
  something you would want your students to go through in order to learn
  it.  On the contrary, "obvious" is extremely hard to pin down before the
  fact, and, well, obvious after the fact.

| Someone else has noted that CLTL2 goes from a formal description to bad
| examples--nothing useful there to a student.

  It depends on the experience of the student.  As a friend commented in
  mail, having used and known TOPS-10/20 makes it so much easier to figure
  out how pathnames work and why they are designed the way they are, with
  what they humorously called "pathological devices" which were very close
  to logical pathnames in design (and which caused me to misunderstand the
  word "pathological" as used elsewhere for a few years :).

  For someone who has only seen Unix or MS-DOS, pathnames are incredibly
  complex beasts, but for the more likely audience of CLtL2, which was not
  published at a time when it was clear that Unix would be only file system
  paradigm to survive (whatever Microsoft does is just copying Unix).

| Well, some students can read a formal description and "get it".  I need
| examples, and that is the big problem I have with this subject (and
| throwing in the variability of OS- and implementation-dependence
| massively does not help, tho mebbe that cannot be helped).

  It would probably be more useful to find examples of how filenames were
  named in VMS, TOPS-10, TOPS-20, Multics, PrimeOS, ITS, etc, all of which
  I had used or read about at the time I faced the pathname specification.

Because some Lisp vendors were nearsighted and thought they would always
have local file systems only, they didn't want to bog down CL syntax in
requiring this.  They were also confused about the issue of this infringing
their ability to "look native".  They really wanted to do
 (with-open-file (stream "c:foo.txt")
   ...)
and not bother people about C being a host.  On the LispM, you have to
write ":c:foo.txt" and people somehow felt this would seem like it was not
favoring the host operating system.

The virtue of the LispM way of doing it is that any call to OPEN can open
any host anywhere on the internet with no special syntactic modification.
All programs are naturally prepared for generality.  (I'd liken this to the
design of the Next operating system, where they chose instead of black&white
screens in their low-end thing to always have at least 2 bits of gray, so
that no one would ever write code that failed to ask how wide a pixel was.
It's an important conceptual stretch to make.)

THere was some further confusion about whether the host colon convention
would preclude people from having a (NAMESTRING-FOR-HOST hosted-namestring)
or a (PARSE-NAMESTRING-FOR-HOST unhosted-namestring host) operation.  Poeple
just didn't want to get involved in hosts at all.

In fairness, the only people with a truly legitimate objection were
the DEC VAXLISP people, who had chained hosts in VMS.  One could refer
in their name syntax to A::B::C::... or some such to say "ask A to
contact B to contact C" in order to find out something.  ANd this
didn't fit in the Lisp file host model at all well.  But then, they
didn't survive commercially...

The LispM had some similar issues which it accomodated with vertical bars.
e.g., a possible file name might be:

  INTERNET|1.2.3.4|FEP0:>boot.boot.37

I think Lisps hould never open a pathname that is not fully defaulted,
while #P"FOO;BAR;" is a valid pathname, it does not necessariliy correspond
to a valid host filename.  Translation is not done until merging is complete
or until trnaslation is specifically forced.  So you can carry around a
fragment as a valid pathname and fill it in later.  But it is not appropriate
to assume that opening FOO;BAR; will open a non-directory pathname /foo/bar
even if such a filename exists.  That's just a program error.

;FOO;BAR; is relative.

I dont agree with programs I've seen by people that do MYLOGHOST:FOO.LISP
and expect it to port right.  What I often do if I need to make a
 /foo
that is the parent of all FOO: files, and that has files in it is to
translate "FOO:FOO;" or "FOO:HOME;" or something like that to
"/foo" and then translate "FOO:*;" to "/foo/*/" with just that one
directory as a hole in it.

 (make-pathname :host myloghost :directory '(:relative) :defaults foo)

will not merge the directory from FOO.  Only

 (make-pathname :host myloghost :directory nil :defaults foo)

will grab the dir.  You're right that under MERGE-PATHNAMES, you'll want
(:relative) or NIL rather than (:absolute), but I would prefer to report
to a vendor as a bug any attempt to say that "MYLOGHOST:FOO.BAR" is anything
but a relative pathname.  If it works at all, and it does in some
implementations, I think that's because there simply _is_ no directory to
merge, even in *DEFAULT-PATHNAME-DEFAULTS* and so an incomplete namestring
is passed onto the operating system, opening the current working dir will
fill out the rest... but not all operating systems even have that, and I
don't like to depend on it.

Given this paragraph and some other comments
written by you in this (and other) thread maybe
you could do something about it.
You said some time ago that you had a project to
write a book (or two) and IMHO you have enough
power (or credit) within the lisp community to set
a de-facto standard in some aspects of the CLHS
that are not clear enough. You could fill holes
and gaps, point to design flaws (not trying to
correct them so we'll have a lisp branch, just
warning and giving advice about them) and
explaining how things should work.

Writing a book these days isn't big bussines but I
think that given your big experience in lisp and
your kwnodledge of the spec, a book by you would
be an inmense help to the lisp community. It would
help users and implementors to agree in the dark
corners of the spec.

Maybe this book wont be such a bad bussines. I
guarrantee you that I'll buy a copy (and I'm sure
that more of 50% of c.l.l will do too :)

--

| Kent M Pitman wrote:
| > Kenny Tilton <ktil...@nyc.rr.com> writes:
| > have once said about thesis writing: If I'd had more time, I would
| > have written less.
|
| Great line, one of my favorites. I feel the same way about code. But
| it was Samuel Clemens, wrapping up a letter to a friend I think.

  I have made this [letter] longer than usual, only because I have
  not had the time to make it shorter.
  -- Blaise Pascal (1623-1662), in Lettres Provinciales (1657) no 16.

Source:  Oxford Concise Dictionary of Quotations, ISBN 0-19-280070-1.

  This is indeed a bit naive.  The ANSI Standard is a legal document,
  effectively an attachment to the contract you sign with your vendor when
  you purchase (a license to) a Common Lisp system that purports to conform
  to it.  Its legal status is well known and effectively peer-reviewed
  through the standardization process.  Relying on the personal commentary
  of the editor of the standard reduces the legal standing of the standard
  so much that it is effectively useless as such, and ANSI would have the
  right to protect its brand name (if not investment) by any means it might
  find necessary.  I would not want to be Kent Pitman if ANSI got pissed at
  him for publishing such _official_ commentaries outside of the process
  that created the standard, basically because it would open up for
  lawsuits against ANSI for failure to follow proper procedures to ensure
  that no particular vendor was unduly favored in its creation.

| Writing a book these days isn't big bussines but I think that given your
| big experience in lisp and your kwnodledge of the spec, a book by you
| would be an inmense help to the lisp community.  It would help users and
| implementors to agree in the dark corners of the spec.

  If it did, it would be a dangerous document.

| Maybe this book wont be such a bad bussines. I guarrantee you that I'll
| buy a copy (and I'm sure that more of 50% of c.l.l will do too :)

  I would buy one, too, just as I bought The SGML Handbook by Charles
  Goldfarb when ISO 8879 turned out to be fairly unreadable by itself, but
  that was before I had legal training and worked with lots of lawyers.

  A standard is _specifically_ relinquished from anyone's personal control
  and left to the community of people that adopted it by its representative
  and proxies.  To re-acquire personal control over it would diminish the
  value of the whole standardization process, just as if a politician who
  had helped push a particular law instructed the courts to interpret it a
  particular way.  (Perhaps you have be really _deeply_ into politics and
  law to see why this is fantastically bad karma, but trust me: it is.)