[detailed discussion of my examples deleted for brevity]

First of all thanks for taking the time for such a detailed answer. I
get the feeling that this thread might finally push me into the right
direction to understand pathnames. I hope it's the same with others
who also expressed their problems with this concept.

I'll try to keep the ball rolling by reading the rest of the CLtL2
chapter tonight and by trying out more examples and asking more
questions here.

Now let my try a simple example: Suppose I've written an application
that magically creates HTML pages from PDF files that look exactly
like the original document on all browsers. The program would ask the
user to specify the location of the PDF file and would create an HTML
file in the same location with a different suffix (or probably create
a subdirectory with a name derived from the name of the PDF file and
store the HTML file there). It is also likely that the application
will have to create some GIF or JPEG files and store them
somewhere. Now I probably would write it such that the user's input is
of course a namestring in the native language of his file system. I
could then convert this namestring to a pathname and manipulate its
type component (which is obviously more general a concept than
'suffix') to be "HTML" instead of "PDF" to generate a pathname for the
resulting HTML document. I could also append the name component of the
pathname to its directory component to create a directory next to the
PDF document to hold the HTML file and the pictures belonging to it.

Now that I think of it this really sounds more portable and elegant
than fiddling with the namestrings themselves. Also, if someone
invents a wonderful new operating system tomorrow I'll 'just' have to
wait for a matching CL implementation and chances are good that my
application will work fine although I didn't even know the new file
system when I wrote it. Hmm, sounds good... :)

Is that the way pathnames are intended to be used?

(I still can't imagine what I would do with the device and host
components but this is obviously due to my limited knowledge of file
systems that aren't derived from Unix. See below.)

Thanks again for your time. I'll be back with more questions in the
next days.

Edi.

--

Dr. Edmund Weitz
Hamburg
Germany

Edi.

--

Dr. Edmund Weitz
Hamburg
Germany

ANSI warned us in the very first X3J13 meeting not to ever interpret
the standard.  This is why I am much more prone publicly to say that
off the wall interpretations are possible than I am to say that off
the wall interpretations are out to lunch.  If reasonable people read
the standard oddly, that's a weakness of the standard, not a fault of
those reasonable people.  And I define "reasonable people" less by the
outcome they achieve (as might seem the intuitive way of doing it) and
more by their "stake".  That is, anyone who has built an implementation
or a large system in CL is, by my definition, entitled to be a reasonable
person.  They have a stake in the game and no reason to be undermining the
community.  Their time and monetary investment in the language is sufficient
to me to say their position must be taken seriously.  Occasionally, people
who've done little more than open the spec to a random page and get
confused complain of something and I sometimes go out on a limb and suggest
they need further reading....

I will at some point do some style advice as part of my emerging books.
Style guides are no problem legally.  Everyone does them.

But really it requires the community as a whole to build consensus on what
it wants, and the best start on that is experience by users of deployed
vendor interpretations.  I don't think any single person can simply declare
one user base right and one user base wrong.  If, on the other hand, one
user base is always dissatisfied and another is not, the dissatisfied group
might want to hammer on their vendor to be more like the vendor who's
supplying their happier pals.

I am constantly reminding people of this and I get people poking fun
at me about false humility when I say "I'm just another opinion" but
it is this legal aspect, not any issue of humility (false or
otherwise), that causes me to continue to mention it.  My credential
as Project Editor merely entitles me to say "I was a historically
close observer and am more than likely relaying firsthand information,
if I am neither misremembering or misstating or just lying, any of
which is in principle possible if you don't know enough about me to
believe otherwise."  As a firsthand observer, I am certainly privvy to
some knowledge about things that were said in conjunction to the
standard's creation, but I am no moreso than any other participant who
was alwys there.  And has been observed about witnesses to crimes,
memory is not black&white, and people can reasonably disagree on
things they saw with their own eyes.

If KMP writes such book he deserves a medium-big
pile of cash, but maybe he wont get it.

--

When I say "no one wanted them", I don't mean it in the casual sense that
someone here, for no cost, can stand up and say "I did".  I mean in the
more formal sense of "It would cost a lot, and when push came to shove, an
insufficient amount of money and energy was not rendered to create the
necessary processes".  Perhaps that will change.  But I honestly doubt the
need.  That's not to say it's impossible.  I'm just saying that the present
situation is just not so intolerable that it's worth the dollar trade of
spending money on "really" fixing the problems instead of spending money on
merely working around the problems.  They're not that hard to work around,
and people have more important things to do.  Perhaps a patron will come
along and fix things some day, but it is no small expense to get real
community consensus and it is quite a small expense to learn how to use
these facilities judiciously and how to use #+/#- in the few places they
fall down.

 (make-pathname :type "HTML" :case :common :defaults what-user-typed)

The whole point of the component-wise pathname setup is to let you
ignore components not relevant to your file system and to assume they
can either be passed straight through or allowed to default.  If we
had not done it this way, you would have to have code in your personal
code to accomodate devices.

For most merging, I mostly just pass devices through "just in case",
though typically them when the host is changing.... What is on C: on
one file system might be on D: on another.  It might matter that you get
the device right, but it won't be done "better" by assuming it's the
same on all systems... It really has to be supplied where it matters.

Certainly when making a file FOO.LISP from another, you should do:

 (make-pathname :name "FOO" :type "LISP" :version nil
                :host      (pathname-host      pathname1 :case :common)
                :device    (pathname-device    pathname1 :case :common)
                :directory (pathname-directory pathname1 :case :common)
                :case :common)

or

 (make-pathname :name "FOO" :type "LISP" :version nil
                :defaults pathname1 :case :common)

[...]

Regards,
Julian

I once half-jokingly suggested we call Lisp "c".  (Note, not "C".  It
would be kinda funny if, in order to go after us legally for some kind
of trademark infringement and/or fraud, the "C" community had to admit
that case sensitivity wasn't really a good way of keeping name
collisions from happening....)

  When I decided to design a real markup language in the spirit of Common
  Lisp, I called it NML (for New/Naggum/whatever Markup Language),
  prnounced "enamel", and joked that the Common Lisp with <> instead of ()
  would be XCL, X for the hackneyed "extensible".  I wanted the Common Lisp
  reader to be told how to parse elements according to the first symbol in
  a list.  Like, <strong x> should read as a NML element of type strong
  with the string "x" as the contents.  Now, you would have to declare any
  symbols that would be read this way.  The default would be parse the
  contents as XCL, but then it dawned on me that this could be read as XCl,
  and considering that simple chlorides are also called "salts", figured
  that it would be "salt contents".

  There are lots of interesting things to say about "salt" as a name for a
  language.  The Next ANSI Common Lisp would be the Common Salt, NaCl.
  "Salt" is the etymological base for "salary", emphasizing the commercial
  value of the langauge, and its ancient value is found in expressions like
  "worth his salt", emphasizing a high standard of value, etc.

| I once half-jokingly suggested we call Lisp "c".  (Note, not "C".  It
| would be kinda funny if, in order to go after us legally for some kind of
| trademark infringement and/or fraud, the "C" community had to admit that
| case sensitivity wasn't really a good way of keeping name collisions from
| happening....)

  Devious...  :)

| The only place I've seen case-sensitivity usefully used is in situations
| like &ntilde; vs &Ntilde; in XML, where you want either n + ~ or N + ~
| depending on what case you've used.  That is, only when actually trying
| to talk about the alphabet itself, which presumably really does want case
| sensitivity at some level or wouldn't have upper and lower case at all.

  Chemical formulae tend to need case to distinguish between the elements.
  A symbol that held the name of symbols could of course be printed with
  the capitalize notation, and individually be unique, anyway...

would this be possible?
would this be efficient?
how do you write your "own" glue code between the pathname frontend
and low level backend?

Regs, Pierre.

Incidentally, here's a story about pathnames.  Our system runs on
Windows and *nix (currently Linux).  It does a fair amount of stuff to
do with fetching things from remote servers which it currently does
with rsync (it could use other mechanisms but rsync is the only
implemented one).  On windows it uses the cygwin rsync (it needs other
bits of cygwin, like gcc, anyway).

The largest, most unpleasent and least portable bit of
platform-dependence is because of rsync.  If you are mirroring from a
local filesystem on Windows you typically want to say

        rsync c:/... d:/....

But rsync *knows* deep in its little black heart that this means `the
host named c'.  So what you have to do is realise that cygwin always
maps c: to /cygdrive/c (I think this is right) and rewrite pathnames
appropriately.

  NaCl is the chemical formula for pure, clean salt, with no additives,
  nothing.  There is nothing to remove from it, so Scheme would not apply.

(make-pathname :host "SYS" :directory '(:absolute) :name "FOO")

be printable?

Kent M Pitman <pit...@world.std.com> writes:

(let ((p (parse-namestring "/zut"))) ; No trailing slash.
   (format t "directory: ~S~%name: ~S~%type: ~S~%"
           (pathname-directory p)
           (pathname-name p)
           (pathname-type p)))

(Note the convenient omission of host, device and version from the
example :) ).

Cheers

Cheers

The professor who taught me the above mentioned method to define the
tangent space of a manifold, a widely known differential geometer,
is a big friend of good wine.  He uses to invite his favorite scholars
to parties in his apartment where he serves samples of his exquisite
wine cellar.  Not many of them are able to walk home in a linear
fashion when those are over.

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

| * Nils Goesche wrote:
|
| > It is a sad fact that one seems to lose much of the ability to tell
| > what a beginner finds hard to understand and what not when one is
| > too deep into a subject.  Books that explain to beginners how to
| > define the tangent space of a manifold always choose some method that
| > takes lots and lots of pages and intricate computations, although
| > there is a method that is not only more general but also so easy and
| > short that you can write it down and explain it on a freakin' beer
| > mat (I did).
|
| Can it be done with text? if it can I'd like to hear it!

Getting a bit off-topic here, are we?  I don't know what definition
Nils has in mind, but there are lots of equivalent definitions out
there.  My favorite is this:

The tangent space of manifold M at a point P is the set of derivations
of the smooth functions at P.  Here, a derivation at P (and hence a
tangent vector) is a linear map from the smooth functions on M to the
reals so that, for any two smooth functions f and g,

  X(fg) = X(f)·g(P) + f(P)·X(g).

(I hope most of you read this using the latin 1 charset, where · is a
dot (for multiplication).)  Note that this looks like a rule for some
sort of differentiation, e.g., a partial derivative, at P.

One canonical example is given by a smooth curve gamma in M with
gamma(0)=P: Define Xf as the derivative of f(gamma(t)) wrt t at t=0.

It's a fairly short calculation (using a kind of first order Taylor's
formula) to show that every tangent vector can be constructed from a
path in this way.  And then it's an even shorter step to express the
general tangent vector as a linear combination of partial derivatives
arising from some smooth map on the manifold.

Now I think this is very short and sweet, but the abstraction level
may be way too high for beginners, which is why textbooks often choose
a more complicated definition, typically starting with expressing a
tangent vector in coordinates and then considering what happens when
you change to a different coordinate system.

Now I am curious as to whether Nils had this or something else in
mind.  I have never tried writing this one on a beer mat.