logical pathnames - lack of info?

[Julian Stecklina]

Hello,

I searched ANSI Common Lisp and On Lisp by Paul Graham, but both seem
to ignore the topic of logical pathnames or pathnames in general. The
Hyperspec is a little vague about that topic and I could not find some
kind of tutorials. CLiki and the Cookbook do not provide any
information either.

Can anybody help?

Regards,
Julian

--
Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/

[Nils Goesche]

In article <877kp6h...@blitz.comp.com>, Julian Stecklina wrote:
> I searched ANSI Common Lisp and On Lisp by Paul Graham, but both seem
> to ignore the topic of logical pathnames or pathnames in general. The
> Hyperspec is a little vague about that topic and I could not find some
> kind of tutorials. CLiki and the Cookbook do not provide any
> information either.
>
> Can anybody help?

You could check out CLTL2 (Common Lisp the Language) first and then try
the HyperSpec again.

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

PGP key ID 0x42B32FC9

[Kent M Pitman]

Nils Goesche <car...@cartan.de> writes:

> In article <877kp6h...@blitz.comp.com>, Julian Stecklina wrote:
> > I searched ANSI Common Lisp and On Lisp by Paul Graham, but both seem
> > to ignore the topic of logical pathnames or pathnames in general. The
> > Hyperspec is a little vague about that topic and I could not find some
> > kind of tutorials. CLiki and the Cookbook do not provide any
> > information either.
> >
> > Can anybody help?
>
> You could check out CLTL2 (Common Lisp the Language) first and then try
> the HyperSpec again.

I'm always mystified by questions like this.

Here is the answer Julian should be looking for:

Logical pathnames offer a uniform naming syntax for pathnames
so that systems that require loading a lot of filenames can be
moved from one host file system to another without regard to
changes to the underlying syntax.

A logical pathname is mapped to the underlying host in a way that
is defined once for each host, and the rest of the system just
refers to the logical pathname and lets the mapping take care of
what underlying physical pathname is used.

The main thing one _does_ with logical pathnames is use them as if
they were a native host syntax on a virtual machine. In that regard,
they are just like regular pathnames. All the operations on logical
pathnames other than the SETF of LOGICAL-PATHNAME-TRANSLATIONS are
largely for debugging. Mostly all you really need to do is set up
your pathnames per SETF of LOGICAL-PATHNAME-TRANSLATIONS and then
use the pathname.

I'd be surprised if it doesn't say this somewhere already, but maybe
it's scattered here and there or maybe it's really omitted. I'm also
surprised if there's anything unclear about this such that more
information is really required. But what would really help those of
us who've designed or have been the system for a long time, rather
than a cry of "there's no documentation", is a statement of what you
can't figure out. For those of us who've used them forever, their use
seems so amazingly obvious that it's hard to figure out what to say.

For example: Are you just learning them speculatively and unable to
envision a use? Are you after a particular prolbem that they don't
seem to solve? Are you starting from already having an understanding of
pathnames?

In many ways, pathname objects solve the same problems as pathnames, but
for some reason many people (even many Lisp programmers) don't really like
using slot-filling to manipulate pathnames and would rather use FORMAT
on strings. In some ways, a logical pathname is a way of re-solving the
problem already solved by pathname objects in the string domain, if that
makes any sense. (See? Asking for an explanation doesn't necessarily
simplify things... ;-)

Anyway, it's ironic (but not uncommon) to receive a gripe about
vagueness that is itself so vague that one cannot figure out what to
offer in response...

[Nils Goesche]

In article <sfwpu2y...@shell01.TheWorld.com>, Kent M Pitman wrote:
>
> I'm always mystified by questions like this.
>
> Here is the answer Julian should be looking for:
>

[snip explanation]

>
> I'd be surprised if it doesn't say this somewhere already, but maybe
> it's scattered here and there or maybe it's really omitted. I'm also
> surprised if there's anything unclear about this such that more
> information is really required. But what would really help those of
> us who've designed or have been the system for a long time, rather
> than a cry of "there's no documentation", is a statement of what you
> can't figure out. For those of us who've used them forever, their use
> seems so amazingly obvious that it's hard to figure out what to say.

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). But I have never seen it printed somewhere. I learned
it from a professor in differential geometry. He always presents it,
among other methods, too, in his lectures, but is perfectly aware of
the fact that not a single one of the listeners seems to be able to
understand it. I didn't either the first time I heard it, although
I absolutely can't remember what my problems with it were. Later
on, I tried to explain it to beginners, too, more and more slowly.
But noone ever got it.

[Kenny Tilton]

Kent M Pitman wrote:
>
> For those of us who've used them forever, their use
> seems so amazingly obvious that it's hard to figure out what to say.

if they are amazingly obvious they should be easy to explain, and I have
never seen a good explanation. Nor have I seen good examples of their
use, which would be better. PATHNAME being implementation dependent in
ways that broke my code sucked a big one. The doc I have seen is
impenetrable. It's like New York City street signs: if you already know
the way, they make sense.

Tell you what: if I ever understand them I'll add an explanation to the
cookbook. Actually, might be a fun way to figure them out, and much
better for a know-nothing to explain them than someone who thinks they
are obvious.

> Anyway, it's ironic (but not uncommon) to receive a gripe about
> vagueness that is itself so vague that one cannot figure out what to
> offer in response...

the doc is so bad we cannot even formulate questions, that is why we
simply ask where to find good doc.

--

kenny tilton
clinisys, inc
---------------------------------------------------------------
"Be the ball...be the ball...you're not being the ball, Danny."
- Ty, Caddy Shack

[Erann Gat]

In article <sfwpu2y...@shell01.TheWorld.com>, Kent M Pitman

<pit...@world.std.com> wrote:

I think you'd better be surprised then. It's impossible to prove a
negative of course, but I've done a fair amount of reading, and I've never
seen such a pithy summary. I remember being mystified by logical
pathnames for a very long time. In fact, I'm still mystified by them, and
I'm not exactly a newbie.

> I'm also
> surprised if there's anything unclear about this such that more
> information is really required. But what would really help those of
> us who've designed or have been the system for a long time, rather
> than a cry of "there's no documentation", is a statement of what you
> can't figure out. For those of us who've used them forever, their use
> seems so amazingly obvious that it's hard to figure out what to say.

I relied mainly on CLTL2 when I tried to learn logical pathnames. (I
eventually gave up on them and wrote my own logical pathname translator.)
Steele goes straight from the formal syntax into a long list of examples
that I found rather impenetrable.

Here are some specific questions that arose in my mind as I was struggling
with this topic. Some of them I still don't know the answer to.

1. What is the distinction between a logical pathname translation and a
logical host? (BTW, your little intro above was very good, but I would
like to have seen a fourth paragraph introducing the concept of a logical
host. It seems to be rather central.)

2. The vast majority of things that manipulate persistent global state in
Common Lisp seem to be done with DEF- macros. defun, defstruct, defclass,
etc. We don't typically see (setf (symbol-value blarg) (lambda ...))
Since logical pathname translations are persistent global state I would
expect them to be set up with something like DEF-LOGICAL-PATHNAME or
something like that, but they aren't. They are set up with a SETF. Is
there a reason for this non-orthogonality in design?

3. What are the rules for matching up wildcards in the from-pathname and
the to-pathname? Why wildcards instead of a more general patthern
syntax? The wildcards seem very unlispy, and seem to prevent you from
doing potentially useful things like reversing the order of two pathname
components.

I could go on.

E.

[Kent M Pitman]

g...@jpl.nasa.gov (Erann Gat) writes:

> Here are some specific questions that arose in my mind as I was struggling
> with this topic. Some of them I still don't know the answer to.
>
> 1. What is the distinction between a logical pathname translation and a
> logical host? (BTW, your little intro above was very good, but I would
> like to have seen a fourth paragraph introducing the concept of a logical
> host. It seems to be rather central.)

A logical host is a datatype that is a conceptual child of the non-datatype
"file host" which is for reasons of lack of convergence not present in CL,
but which designates a particular instance of a named file system. That is,
a logical host is just another class like MSDOS-HOST or UNIX-HOST that
provides information on how a certain class of files is parsed; and the
"SYS" logical host is an instance of that host... except we don't happen to
specify all the class names so we just dance around it vaguely and let you
use what amount to host-designators rather than hosts as a result.

Logical pathname translations are alists. They are likely to be among the
slot values of a logical host. But they don't, for example, contain the
name of the logical host.

So the question is a lot like the question "what's the difference between a
symbol and its property list?"

> 2. The vast majority of things that manipulate persistent global state in
> Common Lisp seem to be done with DEF- macros. defun, defstruct, defclass,
> etc. We don't typically see (setf (symbol-value blarg) (lambda ...))
> Since logical pathname translations are persistent global state I would
> expect them to be set up with something like DEF-LOGICAL-PATHNAME or
> something like that, but they aren't. They are set up with a SETF. Is
> there a reason for this non-orthogonality in design?

Yes: Committee design sucks.

The Lisp Machine, from which this was all drawn, had such things. But it was
important to some set of people on the committee that we not just favor the
Lisp Machine by doing things its way, so we instead made sure everyone was
equally unhappy by using no one's design. Fairness comes in strange forms.

You were expecting perhaps a technical answer? What have I told you about
that?

> 3. What are the rules for matching up wildcards in the from-pathname and
> the to-pathname?

Doesn't translate-pathname tell you? It's mostly system-specific.

> Why wildcards instead of a more general patthern
> syntax?

So that the native host file system can manage this.

> The wildcards seem very unlispy, and seem to prevent you from
> doing potentially useful things like reversing the order of two pathname
> components.

No they don't. They just keep you from doing it with filename syntax.
These things can still be dealt with in object-oriented fashion.

> I could go on.

That's up to you. I can't go on without more questions to answer.

[Dr. Edmund Weitz]

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

> I can't go on without more questions to answer.

OK, I'll try my luck.

In trying to understand what's happening and how implementations use
the concept of pathnames I booted my laptop into Windows and played
around with various CL systems. Here's an excerpt of what I got:

1. Allegro CL:

CG-USER(1): (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
*MY-NAMESTRING*
CG-USER(2): (probe-file *my-namestring*)
#p"c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs"
CG-USER(3): (type-of *)
PATHNAME
CG-USER(4): (defparameter *my-pathname* (pathname *my-namestring*))
*MY-PATHNAME*
CG-USER(5): (pathname-host *my-pathname*)
NIL
CG-USER(6): (pathname-device *my-pathname*)
"c"
CG-USER(7): (pathname-version *my-pathname*)
:UNSPECIFIC

2. LispWorks:

CL-USER 18 > (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
*MY-NAMESTRING*
CL-USER 19 > (probe-file *my-namestring*)
#P"c:/Documents and Settings/Administrator/Desktop/Love-letter-for-you.txt.vbs"
CL-USER 20 > (type-of *)
PATHNAME
CL-USER 21 > (defparameter *my-pathname* (pathname *my-namestring*))
*MY-PATHNAME*
CL-USER 22 > (pathname-host *my-pathname*)
"c"
CL-USER 23 > (pathname-device *my-pathname*)
NIL
CL-USER 24 > (pathname-version *my-pathname*)
NIL

3. CormanLisp:

(defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
*MY-NAMESTRING*
(probe-file *my-namestring*)
"c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs"
(type-of *)
(VECTOR CHARACTER)
(defparameter *my-pathname* (pathname *my-namestring*))
*MY-PATHNAME*
(pathname-host *my-pathname*)
NIL
(pathname-device *my-pathname*)
"c"
(pathname-version *my-pathname*)
:UNSPECIFIC

4. CLISP

[10]> (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
*MY-NAMESTRING*
[11]> (probe-file *my-namestring*)
#P"C:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs"
[12]> (type-of *)
PATHNAME
[13]> (defparameter *my-pathname* (pathname *my-namestring*))
*MY-PATHNAME*
[14]> (pathname-host *my-pathname*)
NIL
[15]> (pathname-device *my-pathname*)
"C"
[16]> (pathname-version *my-pathname*)
NIL

No two of these implementations return the same results. (CormanLisp
and AllegroCL agree on the pathname components but differ in the type
of PROBE-FILEs return value.) I'm sure there are more differences, and
I can imagine the situation on Linux/Unix to be similar.

From my understanding of the CLHS all this seems to be correct
behaviour. I also understand that it can't be the duty of the ANSI
standard to define how the pathname concepts should map to various
operating systems (that maybe didn't even exists when the standard was
written) and that expecting consistent behaviour of all
implementations on the same platform might be asking too much from the
vendors. But I wonder what I should make of this.

Assume I'm writing an application with ACL for Windows but I want it
to be portable to LispWorks and CormanLisp as well. Furthermore, I
might want to target the Linux market with the same application later
on. It looks like I have to resort to namestrings (which is as
unportable as it could be) if I want to specify the exact location of
a file in the filesystem. Now you could argue that I can convert these
namestrings to pathnames because it would make it easier to manipulate
the components. But if I do this, I can't be sure that the same
component names the same thing in different implementations. Hmmm...

Given this and older threads on c.l.l about similar problems (like
that you can't portably tell whether a 'file' is a 'directory') I
can't see the merits of all this at the moment.

I think some examples might be enlightening. Are there any
applications out there that work across different implementations
and/or operating systems without resorting to implementation-specific
functions although they do significantly complex operations on file
locations (say, something more sophisticated than going :UP or :BACK
one or two directories)? Probably with source code available so that
one can try to understand what they do and how they do it?

BTW, thanks to Nils for hinting at CLtL2. I've never really looked at
it because it was my impression from this newsgroup that it was just
an attempt to write down the standard before it was passed. I started
to read the chapter about files last evening and I have to admit that
it is the best treatment of this topic I've seen so far.

Thanks in advance for your help,
Edi.

Disclaimer: Apart from some faint memories of systems like NOS/VE (was
that from DEC? I can't remember), TOS, CP/M, I've only
dealt with the systems that seem to be in wide-spread use
today - Unix, Mac, DOS/Windows. I understand that
historically CL had to cope with many other filesystems
that I've never used personally and I regard it as an
heroic effort to even try to invent an abstract concept
that applies to all of them. I just wonder if it wasn't
futile.

PS: All commercial implementations used in the examples above are the
current (trial) versions available from the respective
websites. CLISP is the newest binary release available.

--

Dr. Edmund Weitz
Hamburg
Germany

The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>

[Erik Naggum]

* Kenny Tilton <kti...@nyc.rr.com>

| if they are amazingly obvious they should be easy to explain

Quite the contrary. The obvious eludes explanation. It usually takes a
trained philosopher to see things are obvious to most people from an
unobvious angle and describe it back to them in terms that interest them
much more than the obvious matter at hand would.

| the doc is so bad we cannot even formulate questions, that is why we
| simply ask where to find good doc.

I find this a rather peculiar position, but since I read this from the
specifications and tend to use pathname translations to provide a virtual
file system that is far easier to maneuver than the physical file system
I have to work on, I really do wonder what the problem is.

///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.

[Kent M Pitman]

e...@agharta.de (Dr. Edmund Weitz) writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > I can't go on without more questions to answer.
>
> OK, I'll try my luck.
>
> In trying to understand what's happening and how implementations use
> the concept of pathnames I booted my laptop into Windows and played
> around with various CL systems. Here's an excerpt of what I got:
>
> 1. Allegro CL:
>
> CG-USER(1): (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
> *MY-NAMESTRING*
> CG-USER(2): (probe-file *my-namestring*)
> #p"c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs"
> CG-USER(3): (type-of *)
> PATHNAME
> CG-USER(4): (defparameter *my-pathname* (pathname *my-namestring*))
> *MY-PATHNAME*
> CG-USER(5): (pathname-host *my-pathname*)
> NIL

IMO, this is a bug. I don't think a pathname can legitimately have a
null value for host under ANSI CL.

> CG-USER(6): (pathname-device *my-pathname*)
> "c"

I think it's an annoyance that this isn't an uppercase "C" since the native
OS uses uppercase, but I personally prefer seeing "C" as a device rather
than as a host (which is what LispWorks does).

> CG-USER(7): (pathname-version *my-pathname*)
> :UNSPECIFIC

That's normal for most modern operating systems (Windows, Linux, Mac).
I think there's some ISO file system (ISO9000?) that's still "current"
and has versions, and there are a number of older operating systems with
versions.

> 2. LispWorks:
>
> CL-USER 18 > (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
> *MY-NAMESTRING*
> CL-USER 19 > (probe-file *my-namestring*)
> #P"c:/Documents and Settings/Administrator/Desktop/Love-letter-for-you.txt.vbs"
> CL-USER 20 > (type-of *)
> PATHNAME
> CL-USER 21 > (defparameter *my-pathname* (pathname *my-namestring*))
> *MY-PATHNAME*
> CL-USER 22 > (pathname-host *my-pathname*)
> "c"

Again, I'd prefer uppercase here. It saddens me that they think this is a
host, because I think of it as a device. But in their defense, if you think
of it as a designator for an underlying object with more structure, it's
true that C: might denote a FAT file system while D: might be NTFS. As such,
since a "host" is usually structured and a device usually only "named",
it does make some sense that the host would encapsulate this info.

Also, the Lisp Machine, on which this is based, makes a distinction between
"network hosts" and "file hosts" for exactly the reason I just cited. In the
original MIT cadr-series Lisp Machines, CADR27, I believe it was, had three
file systems, each written by different people, each with its own quite
different notation. It would have been _very_ inappropriate for the network
host to have been used to decide syntax info for parsing, etc.

Anyway, I think the bottom line is that I prefer the conceptual way that
Allegro has broken it down, but there are some technical details they have
swept under the rug by what they have done, and I think it's a bug about
their use of NIL as a host; I still don't think NIL-hosted pathnames are
allowed because they can't be distinguished from "host unsupplied" and
because I think a host is always supplied for all CL-provided pathname
creation operations.

> CL-USER 23 > (pathname-device *my-pathname*)
> NIL
> CL-USER 24 > (pathname-version *my-pathname*)
> NIL

This is also legitimate, though I think a bit confusing. We're debating the
color of unicorns here of course; if I say they are black, not white, does a
counterexample exist to prove me wrong? Where there are no versions, it
hardly matters what value goes here. Whatever you put in, as long as only
NIL or :UNSPECIFIC comes back out, I don't think there's a problem.
The LispWorks approach is suggesting that you have not supplied a version
(and you haven't); the Allegro approach is suggesting that you can't supply
a version (and you can't). Both are legitimate.

> 3. CormanLisp:
>
> (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
> *MY-NAMESTRING*
> (probe-file *my-namestring*)
> "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs"
> (type-of *)
> (VECTOR CHARACTER)

I don't think this is right. PROBE-FILE returns a physical pathname or NIL.
You should report this as a bug.

> (defparameter *my-pathname* (pathname *my-namestring*))
> *MY-PATHNAME*
> (pathname-host *my-pathname*)
> NIL

My opinion is that this is wrong, for reasons cited above. It's a
more controversial matter, though, than the matter of what PROBE-FILE
returns.

> (pathname-device *my-pathname*)
> "c"
> (pathname-version *my-pathname*)
> :UNSPECIFIC

I already remarked on these values above.

> 4. CLISP
>
> [10]> (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
> *MY-NAMESTRING*
> [11]> (probe-file *my-namestring*)
> #P"C:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs"
> [12]> (type-of *)
> PATHNAME
> [13]> (defparameter *my-pathname* (pathname *my-namestring*))
> *MY-PATHNAME*
> [14]> (pathname-host *my-pathname*)
> NIL
> [15]> (pathname-device *my-pathname*)
> "C"
> [16]> (pathname-version *my-pathname*)
> NIL

Nothing here I haven't remarked on above.

> No two of these implementations return the same results.

This isn't quite fair. The phrasing you are wanting wants to
acknowledge sameness under the definitions of allowable tolerances.
e.g., probably no two implementations return the same values for
(RANDOM 100), but that doesn't make them wrong. And not all
implementations return the same value of CHAR-CODE-LIMIT, but that
doesn't mean those implementations don't agree on the meaning. So
when you say NIL and :UNSPECIFIC come back from PATHNAME-VERSION, that
doesn't mean implementations don't agree--it means the spec isn't
adequately specific to cause one behavior or the other. Moreover,
when the spec isn't specific, programs should not rely for their
correctness on either behavior. (That's not the same as saying programs
shouldn't detect the difference; it might even affect the output. But
it should not affect the output in a way that is defined to be improper.)

> (CormanLisp
> and AllegroCL agree on the pathname components but differ in the type
> of PROBE-FILEs return value.) I'm sure there are more differences, and
> I can imagine the situation on Linux/Unix to be similar.

Yes.

> From my understanding of the CLHS all this seems to be correct
> behaviour.

Mostly, modulo the two issues (pathname host of NIL, controversial; and
result of PROBE-FILE, non-controversial) I noted.

> I also understand that it can't be the duty of the ANSI
> standard to define how the pathname concepts should map to various
> operating systems (that maybe didn't even exists when the standard was
> written) and that expecting consistent behaviour of all
> implementations on the same platform might be asking too much from the
> vendors. But I wonder what I should make of this.

The thing the creators of the standard made of it was that if the community
ever cared enough, it could make layered standards. Then vendors who wanted
to could adhere to such standards, and vendors who didn't could ignore them.

> Assume I'm writing an application with ACL for Windows but I want it
> to be portable to LispWorks and CormanLisp as well. Furthermore, I
> might want to target the Linux market with the same application later
> on. It looks like I have to resort to namestrings (which is as
> unportable as it could be) if I want to specify the exact location of
> a file in the filesystem.

This is a HUGE leap from what you said above. Why would you say that??

I don't agree at all with this conclusion.

> Now you could argue that I can convert these
> namestrings to pathnames because it would make it easier to manipulate
> the components. But if I do this, I can't be sure that the same
> component names the same thing in different implementations. Hmmm...

What's in the component names has no relevance here. You didn't say whether
the component-names string back to the same thing. For example, whether
you use :version nil or :version :unspecific, the string name of the pathname
should be the same. :unspecific is to nil as &nbsp; it so #\Space -- they
are things that look the same but have different "merging semantics".

> Given this and older threads on c.l.l about similar problems (like
> that you can't portably tell whether a 'file' is a 'directory') I
> can't see the merits of all this at the moment.

I've never found this to be an active impediment to writing code that easily
spans the common implementations. Can you say something specific you want to
do that is not "toy examples" and that actually hampers your work?

> I think some examples might be enlightening.

I'm not going to make up examples here without a framework of a real
program. It is definitely not the case that one can just work from
pathnames to an arbitrary algebra of ideas that works for all
operating systems everywhere. There are too many rough edges. But
most of the common cases do work quite predictably, and I don't
understand why you would think otherwise. I need examples of what you
are saying doesn't work. The above examples of differences are all
things that seem of little or no importance to practical day-to-day
things a programmer really does, which is contributing to my
confusion. Working around all those things you cite is a no-brainer
since none of the things you cite is something that should ever matter.

> Are there any
> applications out there that work across different implementations
> and/or operating systems without resorting to implementation-specific
> functions although they do significantly complex operations on file
> locations (say, something more sophisticated than going :UP or :BACK
> one or two directories)? Probably with source code available so that
> one can try to understand what they do and how they do it?

I use pathnames nearly always, and almost never resort to strings and my
programs usually port just fine. I find pathnames, in spite of their
rough edges and differing implementations in practice, to be one of the
crowning achievements of CL portability.

> BTW, thanks to Nils for hinting at CLtL2. I've never really looked at
> it because it was my impression from this newsgroup that it was just
> an attempt to write down the standard before it was passed. I started
> to read the chapter about files last evening and I have to admit that
> it is the best treatment of this topic I've seen so far.

It does inherit from CLTL the concept of being a tutorial text, which ANSI
CL does not try to be. The only little glitch with CLTL2 is that the
actual semantics it describes are sometimes not the semantics of ANSI CL.
So you have to read with this in mind. But the underlying concepts
are similar.

> Thanks in advance for your help,
> Edi.
>
> Disclaimer: Apart from some faint memories of systems like NOS/VE (was
> that from DEC? I can't remember), TOS, CP/M, I've only
> dealt with the systems that seem to be in wide-spread use
> today - Unix, Mac, DOS/Windows. I understand that
> historically CL had to cope with many other filesystems
> that I've never used personally and I regard it as an
> heroic effort to even try to invent an abstract concept
> that applies to all of them. I just wonder if it wasn't
> futile.

I still use my Lisp Machine today to debug certain kinds of code, and don't
personally regard this as futile. No personal slight intended, but I also
tend to think as a general concept that it's the height of arrogance for
mankind, in general, to use words like "modern" as if these were stable.
Increasingly, as I see things change in the world, I prefer the term
"contemporary" because it acknowledges that today's "modern" will be
tomorrow's "old-fashioned". Just becuase we have Unix, Mac, Windows today
doesn't mean we'll be stuck without versioning forever. I hope someone
will have the good sense to invent it. Certainly it's there for the ISO
file system. CL is not an attempt to be "of the moment", it is an attempt
to be "timeless".

> PS: All commercial implementations used in the examples above are the
> current (trial) versions available from the respective
> websites. CLISP is the newest binary release available.

(It would still be best to name versions by number since figuring out the
correspondences to versions based on the timestamp of your message after
some time has passed and people read this stuff in DejaNews will get
ever harder.)

[Christophe Rhodes]

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

> e...@agharta.de (Dr. Edmund Weitz) writes:

[ACL]
> > CG-USER(7): (pathname-version *my-pathname*)
> > :UNSPECIFIC
[LW]

> > CL-USER 24 > (pathname-version *my-pathname*)
> > NIL
>
> This is also legitimate, though I think a bit confusing. We're debating the
> color of unicorns here of course; if I say they are black, not white, does a
> counterexample exist to prove me wrong? Where there are no versions, it
> hardly matters what value goes here. Whatever you put in, as long as only
> NIL or :UNSPECIFIC comes back out, I don't think there's a problem.
> The LispWorks approach is suggesting that you have not supplied a version
> (and you haven't); the Allegro approach is suggesting that you can't supply
> a version (and you can't). Both are legitimate.

Along similar lines, would you also permit[*] :NEWEST (on a filesystem
that didn't support versions)?

Christophe

[*] I know that you, Kent, are not to be treated as a normative
specification :-)
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

[Tim Bradshaw]

* Kenny Tilton wrote:
> if they are amazingly obvious they should be easy to explain, and I have
> never seen a good explanation. Nor have I seen good examples of their
> use, which would be better. PATHNAME being implementation dependent in
> ways that broke my code sucked a big one. The doc I have seen is
> impenetrable. It's like New York City street signs: if you already know
> the way, they make sense.

Well, I use them all the time. The system I'm working on has all its
sources defined in terms of logical pathnames. The initial `loader'
file bootstraps the logical host from *load-truename*:

(when *load-truename*
(setf (logical-pathname-translations "WELD")
;; Genera used to use ";**;*.*.*", so I used to copy that, but I think
;; this is right.
`(("**;*.*.*" ,(merge-pathnames
(make-pathname
:directory '(:relative :wild-inferiors)
:name :wild
:type :wild
:version :wild
*load-truename*))))))

and from then on everything is defined in terms of this WELD host -
WELD:LOW;PKG.LISP is where the low-level package setup lives, and so on.

Maybe this isn't very advanced usage, but it's a significant win over
having to wire in physical pathnames everywhere...

--tim

[Tim Bradshaw]

* Edmund Weitz wrote:

> Disclaimer: Apart from some faint memories of systems like NOS/VE (was
> that from DEC? I can't remember), TOS, CP/M, I've only
> dealt with the systems that seem to be in wide-spread use
> today - Unix, Mac, DOS/Windows. I understand that
> historically CL had to cope with many other filesystems
> that I've never used personally and I regard it as an
> heroic effort to even try to invent an abstract concept
> that applies to all of them. I just wonder if it wasn't
> futile.

Well one thing you missed is that Windows has at least one other type
of pathname, namely UNC (?) paths - the things that looks like
\\host\share\path...\file.type. Any system that runs on Windows needs
to cope with these things as well as normal physical paths, I think.

[Kenny Tilton]

Tim Bradshaw wrote:
>
> * Kenny Tilton wrote:
> > if they are amazingly obvious they should be easy to explain, and I have
> > never seen a good explanation. Nor have I seen good examples of their
> > use, which would be better. PATHNAME being implementation dependent in
> > ways that broke my code sucked a big one. The doc I have seen is
> > impenetrable. It's like New York City street signs: if you already know
> > the way, they make sense.
>
> Well, I use them all the time.

New York street signs? :)

I/we use logical pathnames all the time, too. I agree the functionality
intended would be useful, I just have never seen comprehensible doc. And
when I tried to create a defsystem for Cells that would work on ACL, LW,
Corman CL and MCL I quickly reminded myself I was interested in sharing
Cells, not mud-wrestling a poorly documented, implementation dependent,
OS variable morass cum language feature.

> The system I'm working on has all its
> sources defined in terms of logical pathnames. The initial `loader'
> file bootstraps the logical host from *load-truename*:
>
> (when *load-truename*
> (setf (logical-pathname-translations "WELD")
> ;; Genera used to use ";**;*.*.*", so I used to copy that, but I think
> ;; this is right.
> `(("**;*.*.*" ,(merge-pathnames

Based on the remark above, I gather you get this stuff to work the way I
do: you have a genetic algorithm that adds and removes *s and ;s and :s
at random until probe-file can find something.

:)

[Kenny Tilton]

Erik Naggum wrote:
>
> * Kenny Tilton <kti...@nyc.rr.com>
> | if they are amazingly obvious they should be easy to explain
>
> Quite the contrary. The obvious eludes explanation.

Not to a good teacher. Good teachers remember what it was like not to
know, and they remember how they got from there to knowing. Or at least
they have taught long enough to have a good guess at where students get
stuck and have a bag of tricks for getting them unstuck. They have a
meta-skill of picking the right trick for each student, and especially
to conjure up over the table (while tutoring) new ways of explaining
tailored to the student and block at hand.

Someone else has noted that CLTL2 goes from a formal description to bad
examples--nothing useful there to a student. 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).

[Julian Stecklina]

Kenny Tilton <kti...@nyc.rr.com> writes:

[...]

> > Anyway, it's ironic (but not uncommon) to receive a gripe about
> > vagueness that is itself so vague that one cannot figure out what to
> > offer in response...
>
> the doc is so bad we cannot even formulate questions, that is why we
> simply ask where to find good doc.

[...]

You speak out of my heart. I never expected my question to start such
big a discussion. The problem of vagueness is that you read it and get
the idea, but in the end there is nothing you can use. It's like
describing the telephone and stating what amazing thing it is to
communicate. But the person never confronted with one actually looks
at the numbers and despairs silently. (Perhaps a vague comparison... *g*)

My questions were the following:

- What are logical pathnames? (seems answered to me)

- How do I use them?

"Mostly all you really need to do is set up
your pathnames per SETF of LOGICAL-PATHNAME-TRANSLATIONS and then
use the pathname."

How?

Sorry Kent, but that is _really_ vague. Ok. I can read the Hyperspec
on that topic. I did. It was quite useless without being introduced to
the topic. Hyperspec is a perfect reference, but nothing to learn
something new that is not similar to something one already
knows. There ought to be a short tutorial to get one started.

[Kent M Pitman]

Christophe Rhodes <cs...@cam.ac.uk> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > e...@agharta.de (Dr. Edmund Weitz) writes:
> [ACL]
> > > CG-USER(7): (pathname-version *my-pathname*)
> > > :UNSPECIFIC
> [LW]
> > > CL-USER 24 > (pathname-version *my-pathname*)
> > > NIL
> >
> > This is also legitimate, though I think a bit confusing. We're debating the
> > color of unicorns here of course; if I say they are black, not white, does a
> > counterexample exist to prove me wrong? Where there are no versions, it
> > hardly matters what value goes here. Whatever you put in, as long as only
> > NIL or :UNSPECIFIC comes back out, I don't think there's a problem.
> > The LispWorks approach is suggesting that you have not supplied a version
> > (and you haven't); the Allegro approach is suggesting that you can't supply
> > a version (and you can't). Both are legitimate.
>
> Along similar lines, would you also permit[*] :NEWEST (on a filesystem
> that didn't support versions)?

I don't see any way in which it should hurt anything for an implementation
to do this, since I don't think well-written code should mind finding
:NEWEST there. The main case I'd expect to find it would be where someone
had constructed the pathname (make-pathname ... :version :newest) and the
implementation had decided that since :newest wasn't an incompatible value,
it would just preserve what it was given. By the same argument, :OLDEST
could also occur.

> [*] I know that you, Kent, are not to be treated as a normative
> specification :-)

Heh. Good of you to save me having to mention that.

[Tim Bradshaw]

* Kenny Tilton wrote:

> Based on the remark above, I gather you get this stuff to work the way I
> do: you have a genetic algorithm that adds and removes *s and ;s and :s
> at random until probe-file can find something.

Oh, no, not at all. I used to just copy what I came across on Genera
(or what I remember from Genera, which may be wrong), but I think it's
clearly incorrect, and after getting bitten by it I changed it and put
the comment in.

The issue is that what I used to do was have pathnames like
WELD:;FOO;BAR.LISP and expect them to translate (say) to
/project/weld/work/tfb/weld-src/foo/bar.lisp. But this is, I think, a
mistake: a logical pathname like WELD:;x;y is a *relative* pathname
(because of the leading ;), and what you want is an absolute pathname,
one without the leading ;.

In all cases where the incantation I now use doesn't work I've
convinced myself that it's an implementation bug (this is not to say
that what I do is not also buggy).

--tim

[Julian Stecklina]

Christophe Rhodes <cs...@cam.ac.uk> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > e...@agharta.de (Dr. Edmund Weitz) writes:
> [ACL]
> > > CG-USER(7): (pathname-version *my-pathname*)
> > > :UNSPECIFIC
> [LW]
> > > CL-USER 24 > (pathname-version *my-pathname*)
> > > NIL
> >
> > This is also legitimate, though I think a bit confusing. We're debating the
> > color of unicorns here of course; if I say they are black, not white, does a
> > counterexample exist to prove me wrong? Where there are no versions, it
> > hardly matters what value goes here. Whatever you put in, as long as only
> > NIL or :UNSPECIFIC comes back out, I don't think there's a problem.
> > The LispWorks approach is suggesting that you have not supplied a version
> > (and you haven't); the Allegro approach is suggesting that you can't supply
> > a version (and you can't). Both are legitimate.
>
> Along similar lines, would you also permit[*] :NEWEST (on a filesystem
> that didn't support versions)?

[...]

The file system might not know about versions, but the implementation can.

Example from CMU CL 18c with test.lisp.0 created before:

* (probe-file "test.lisp.0")
#p"/usr/home/blitz/src/test.lisp.0"

* (pathname-version *)
0

* (pathname-type **)
"lisp"

* (pathname-host ***)
#<COMMON-LISP::UNIX-HOST {280401F5}>

Using :newest for version in pathnames does not work (created test.lisp.1):
* (probe-file (make-pathname :name "test" :type "lisp" :version :newest))
NIL

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

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

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

[Christophe Rhodes]

Julian Stecklina <der_j...@web.de> writes:

> Christophe Rhodes <cs...@cam.ac.uk> writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > > e...@agharta.de (Dr. Edmund Weitz) writes:
> > [ACL]
> > > > CG-USER(7): (pathname-version *my-pathname*)
> > > > :UNSPECIFIC
> > [LW]
> > > > CL-USER 24 > (pathname-version *my-pathname*)
> > > > NIL
> > >
> > > This is also legitimate, though I think a bit confusing. We're debating the
> > > color of unicorns here of course; if I say they are black, not white, does a
> > > counterexample exist to prove me wrong? Where there are no versions, it
> > > hardly matters what value goes here. Whatever you put in, as long as only
> > > NIL or :UNSPECIFIC comes back out, I don't think there's a problem.
> > > The LispWorks approach is suggesting that you have not supplied a version
> > > (and you haven't); the Allegro approach is suggesting that you can't supply
> > > a version (and you can't). Both are legitimate.
> >
> > Along similar lines, would you also permit[*] :NEWEST (on a filesystem
> > that didn't support versions)?
>
> [...]
>
> The file system might not know about versions, but the implementation can.
>
> Example from CMU CL 18c with test.lisp.0 created before:
>

> [CMUCL's rather bizarre version handling]

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

Well, :newest, at a guess, should pick up the file test.lisp.

I'm slightly more worried by :unspecific; what happens if a pathname
with version of :unspecific gets near the filesystem? I would hope
that it (under Unixalikes) is silently ignored and we get the normal
version, but I wouldn't be too surprised if some implementation
somewhere gets it wrong...

Out of interest, what does your CMUCL give for (probe-file :name
"test.lisp" :type "0")?

Christophe

[Kent M Pitman]

Kenny Tilton <kti...@nyc.rr.com> writes:

> Erik Naggum wrote:
> >
> > * Kenny Tilton <kti...@nyc.rr.com>
> > | if they are amazingly obvious they should be easy to explain
> >
> > Quite the contrary. The obvious eludes explanation.
>
> Not to a good teacher. Good teachers remember what it was like not to
> know, and they remember how they got from there to knowing.

Well, in fairness, good teachers are regularly in contact with students,
of whom they routinely see questions and have to ask what those people
asking them see. There's a lot of give and take in teaching. I like
teaching people things because of what I learn, which is why I am not shy
about asking questions like I did here. I don't think the fact of having
to ask diminishes my ability to function in the role of occasional teacher,
unless you assume that my asking the question is somehow the endpoint of my
involvement in that role and that subsequent discussion occurs in some other
role. I didn't say I wouldn't answer; I just asked for more input and
direction in order to offer information that (a) would not be irrelevant to
the person asking and (b) would not waste my time. There are a large number
of things I could say about pathnames if someone were paying me. Discussion
I and others offer here is not billed for, and so I don't take well to
criticisms of our teaching/presentation skill just because we have failed to
offer up either unlimited quantities of undirected information or even failure
to have sat down and spent valuable time thinking about how to condense or
direct our thoughts to saying something smaller. As someone is reputed to
have once said about thesis writing: If I'd had more time, I would have
written less.

> Someone else has noted that CLTL2 goes from a formal description to bad
> examples--nothing useful there to a student. 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).

This is an important observation that immediately enlightens and
saddens me. First, it is now more obvious what one would not get,
when one factors in how little anyone knows about file systems other
than the standard ones.

The real gap here is not understanding pathnames per se, but
understanding a world before commercial homogenization... especially
so because that homogenization is not the result of a group consensus
that other ways of doing things were extra baggage that should go
away, but are rather victims of something analogous to (gosh, I
haven't gotten to do _this_ in a while) a US presidential election,
where you only get one vote and yet you have to by that vote designate
"who you want to have veto power over proposed laws", "whose health
care plan you want", "who you want appointing supreme court justices",
"who you want prosecuting any wars that come up", "who you want
telling the attorney general what to do", etc. etc. That's stretching
a single bit of information just a little far, and nothing ticks me
off more than having the newly elected president take that one bit of
information "I guess Fred is mostly better than Sam" and turning it
into "I completely 100% endorse all of Fred's agendas and completely
100% hate all of Sam's agendas".

Likewise, when we "voted" for Microsoft and Macintosh and even Linux,
we didn't really mean "there are no other good ideas in the world",
what we really meant was more akin to "Gee, this seems to crash seldom
enough or to have enough users who liked the icons that I can do
business here", and not "Gee, I'm so glad to have an operating system
that doesn't have file versioning and 6000 other ideas that I've
examined in detail and fortunately found I completely didn't want any
of".

It is a shame to have lost the many good features of the old operating
systems.

It is further a shame to have lost the memory of those things.

This is a possible thing that could have happened to Lisp itself, by
the way. My biggest fear for the last decade hasn't been that mankind
would fail to survive without it, but that many good ideas in the
language would be incidentally lost and would take forever to reinvent
if Lisp went away, even though the features weren't the cause of the
loss. I'm glad to see Lisp hanging in there.

At least now that I understand that people can't see the world that
pathnames were intended to solve (and sometimes therefore, I think
falsely, reject the very possibility of such a world), they may not
understand what issues are addressed, just as I wonder if anyone born
recently understands what is being referred to in the opening of the
old Outer Limits episodes where it says "We control the horizontal, we
control the vertical..." It's been so long since I saw a modern TV
lose vertical hold that I can only guess what modern people suppose
these phrases to mean.

[Michael Parker]

"Dr. Edmund Weitz" wrote:
>
> Kent M Pitman <pit...@world.std.com> writes:
>
> > I can't go on without more questions to answer.
>
> OK, I'll try my luck.
>
> In trying to understand what's happening and how implementations use
> the concept of pathnames I booted my laptop into Windows and played
> around with various CL systems. Here's an excerpt of what I got:

...

>
> No two of these implementations return the same results. (CormanLisp
> and AllegroCL agree on the pathname components but differ in the type
> of PROBE-FILEs return value.) I'm sure there are more differences, and
> I can imagine the situation on Linux/Unix to be similar.

As Kent mentions, the differences you're seeing are due to either bugs,
or because you're asking for version information on filesystems without
it. I don't remember if it's CLTL2 (probably) or the hyperspec that
mentions that the goal for logical pathnames was to cover enough of the
bases that logical pathnames could, with supporting translations, handle
most of the situations. Whether or not this is good enough in today's
world where 99.99% of the OS's under consideration use pretty unix-like
pathnames is another matter.

> From my understanding of the CLHS all this seems to be correct
> behaviour. I also understand that it can't be the duty of the ANSI
> standard to define how the pathname concepts should map to various
> operating systems (that maybe didn't even exists when the standard was
> written) and that expecting consistent behaviour of all
> implementations on the same platform might be asking too much from the
> vendors. But I wonder what I should make of this.

> Assume I'm writing an application with ACL for Windows but I want it
> to be portable to LispWorks and CormanLisp as well. Furthermore, I
> might want to target the Linux market with the same application later
> on. It looks like I have to resort to namestrings (which is as
> unportable as it could be) if I want to specify the exact location of
> a file in the filesystem. Now you could argue that I can convert these
> namestrings to pathnames because it would make it easier to manipulate
> the components. But if I do this, I can't be sure that the same
> component names the same thing in different implementations. Hmmm...

It's not as big a deal if you use logical pathnames internally and use
pathname-translations to tell lisp where things are. I've got stuff
that
moves between Symbolics Genera, clisp (Linux and 9x/NT), and Lispworks
(9x and NT) just fine. Every project gets it's own logical host, and
the subproject, configuration, and data directories get their own
translation. However, just because logical paths support versions
doesn't mean that all the filesystems do -- they should try to do
something
"reasonable", but that's as good as you can really hope for. At any
rate, really does work better in practice than you're giving it credit
for -- go through the CLTL2 examples and try setting up some of your
projects with logical pathnames, and it'll start making a lot more
sense.

Here's a sample of a (shortened) translation file:

#+:Symbolics
(fs:set-logical-pathname-host "XYZZY"
:physical-host "LOCAL"
:translations '(("XYZZY:XYZZY;**;*.*.*" "LOCAL:>XYZZY>**>*.*.*")
("XYZZY:SYS;**;*" "LOCAL:>XYZZY>**>*")
("XYZZY:COMPR;**;*" "LOCAL:>XYZZY>COMPR>**>*")
("XYZZY:GUI;**;*" "LOCAL:>XYZZY>GUI>**>*")
("XYZZY:DB;**;*" "LOCAL:>XYZZY-DB>**>*") ))

#+:Lispworks
(setf (logical-pathname-translations "XYZZY")
'(("XYZZY:XYZZY;**;*" "c:/projects/lisp/XYZZY/**/*")
("XYZZY:SYS;**;*" "c:/projects/lisp/XYZZY/**/*")
("XYZZY:COMPR;**;*" "c:/projects/lisp/XYZZY/compr/**/*")
("XYZZY:GUI;**;*" "c:/projects/lisp/XYZZY/client-gui/**/*")
("XYZZY:DB;**;*" "d:/xyzzy/db/**/*") ))

[Kent M Pitman]

Julian Stecklina <der_j...@web.de> writes:

> My questions were the following:
>
> - What are logical pathnames? (seems answered to me)
>
> - How do I use them?
>
> "Mostly all you really need to do is set up
> your pathnames per SETF of LOGICAL-PATHNAME-TRANSLATIONS and then
> use the pathname."
>
> How?
>
> Sorry Kent, but that is _really_ vague. Ok. I can read the Hyperspec
> on that topic. I did. It was quite useless without being introduced to
> the topic. Hyperspec is a perfect reference, but nothing to learn
> something new that is not similar to something one already
> knows. There ought to be a short tutorial to get one started.

I'm still missing something here. Here is some more explanation.
Please, in exchange for my having done this, I need these two bits of
information: (a) is there still something missing and (b) if something
here is what you wanted, what were you confused about? That is, what did
you think might be true that wasn't, or what didn't you see that you should
have. This all looks vanilla and basic like it would be obvious from any
reading of any spec on th is matter, but I must still be missing something
about why this is so hard. I'd like to pursue this discussion to the point
of discovering the conceptual roadblock that I am not seeing but you are
having.

- - - -

The logical pathname abstraction creates a virtual file system, just
as a Java creates a virtual machine. You start with something
physical and you layer up a new abstraction.

Logical pathnames refer to files on a logical host. A logical host
named "ZING" is marked by "ZING:".

In the logical host's file system are directories "FOO1", "FOO2",
etc. that are referred to as "FOO1;" , "FOO2;", etc. If you want
subdirs "BAR1", "BAR2", etc. of "FOO1;" you write "FOO1;BAR1;" etc.

Files in a file directory have a name part, a type part, and a version
part. "FOO.LISP" has a name and type. "FOO.LISP.3" has a name and type
and version.

From there, for the most part, you do the same things with logical
pathnames you do with other pathnames. You do stuff like

(with-open-file (x "ZING:FOO1;BAR2;FOO.LISP")
...)

to open such a file, for example. The only difference between what you
would do with this filename and with a system-specific filename like

"mack:foo1:bar2:foo.lisp" ;macintosh
"eunix:/foo1/bar2/foo.lisp" ; unix/linux
"doss:\\foo1\\bar2\\foo.lisp" ; MS DOS

is that the notation for logical pathanames is supposed to work everywhere.
You define, by setting the translations, that

"logmack:**;*.*" is supposed to map to "mack:**:*.*"
or that
"logeun:/*/*.*" is supposed to map to "enuix:/*/*.*"
and "logeun:/*/*/*.*" is supposed to map to "enuix:/*/*/*.*"
and "logeun:/*/*/*/*.*" is supposed to map to "enuix:/*/*/*/*.*"
and so on to some appropriate depth [since Unix has no "**"
wild-inferiors notion].

Using logical pathnames means your application can easily be retargeted
to a different physical host without changing it to use different notations.
e.g., on Unix the names are foo/bar/baz but on DOS they are foo\bar\baz,
but using logical pathname mappings hides this.

[Christopher Browne]

In the last exciting episode, Kent M Pitman <pit...@world.std.com> wrote::

> e...@agharta.de (Dr. Edmund Weitz) writes:
>> CG-USER(7): (pathname-version *my-pathname*)
>> :UNSPECIFIC

> That's normal for most modern operating systems (Windows, Linux,
> Mac). I think there's some ISO file system (ISO9000?) that's still
> "current" and has versions, and there are a number of older
> operating systems with versions.

That would be ISO 9660, used for CD-ROMs.

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...

>> 2. LispWorks:
>>
>> CL-USER 18 > (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
>> *MY-NAMESTRING*
>> CL-USER 19 > (probe-file *my-namestring*)
>> #P"c:/Documents and Settings/Administrator/Desktop/Love-letter-for-you.txt.vbs"
>> CL-USER 20 > (type-of *)
>> PATHNAME
>> CL-USER 21 > (defparameter *my-pathname* (pathname *my-namestring*))
>> *MY-PATHNAME*
>> CL-USER 22 > (pathname-host *my-pathname*)
>> "c"

> Again, I'd prefer uppercase here. It saddens me that they think
> this is a host, because I think of it as a device. But in their
> defense, if you think of it as a designator for an underlying object
> with more structure, it's true that C: might denote a FAT file
> system while D: might be NTFS. As such, since a "host" is usually
> structured and a device usually only "named", it does make some
> sense that the host would encapsulate this info.

>> Disclaimer: Apart from some faint memories of systems like NOS/VE (was

>> that from DEC? I can't remember), TOS, CP/M, I've only
>> dealt with the systems that seem to be in wide-spread use
>> today - Unix, Mac, DOS/Windows. I understand that
>> historically CL had to cope with many other filesystems
>> that I've never used personally and I regard it as an
>> heroic effort to even try to invent an abstract concept
>> that applies to all of them. I just wonder if it wasn't
>> futile.

> I still use my Lisp Machine today to debug certain kinds of code,
> and don't personally regard this as futile. No personal slight
> intended, but I also tend to think as a general concept that it's
> the height of arrogance for mankind, in general, to use words like
> "modern" as if these were stable. Increasingly, as I see things
> change in the world, I prefer the term "contemporary" because it
> acknowledges that today's "modern" will be tomorrow's
> "old-fashioned". Just becuase we have Unix, Mac, Windows today
> doesn't mean we'll be stuck without versioning forever. I hope
> someone will have the good sense to invent it. Certainly it's there
> for the ISO file system. CL is not an attempt to be "of the
> moment", it is an attempt to be "timeless".

I would suggest the term "latter day" somewhat paralleling the Lord of
the Rings style of "dispensationalism" where different groups of
peoples are treated as "dominant," and where the times of the elder
peoples ultimately pass, leaving responsibility to the younger.

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...

Picking at versioning, it's not obvious that it would necessarily
return. The main folks that would remember it would be those that
vaguely remember VMS (probably the language of the dwarves, and of
Mordor, which was taken over to the enemy... wow... it fits...).
And the existant version systems aren't using _integers_ for versions,
so that having FS versioning support wouldn't be forcibly terribly
helpful.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/lsf.html
Never lend your car to anyone to whom you have given birth to.
--Erma Bombeck

[Kenny Tilton]

Kent M Pitman wrote:
>
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
> > Erik Naggum wrote:
> > >
> > > * Kenny Tilton <kti...@nyc.rr.com>
> > > | if they are amazingly obvious they should be easy to explain
> > >
> > > Quite the contrary. The obvious eludes explanation.
> >
> > Not to a good teacher. Good teachers remember what it was like not to
> > know, and they remember how they got from there to knowing.
>
> Well, in fairness, good teachers are regularly in contact with students,
> of whom they routinely see questions and have to ask what those people
> asking them see.

Yes, this is a disadvantage for the technical writer.

> I don't take well to

> criticisms of our teaching/presentation skill just because ...

Not sure if you are referring to my article, but for the record I was
not referring to you at all, and in fact I have no problem with anything
you have said so far in this thread. If the issue is in fact obvious,
someday I will understand it and offer an explanation to the cookbook.

> 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.

[Julian Stecklina]

Christophe Rhodes <cs...@cam.ac.uk> writes:

[...]

> Out of interest, what does your CMUCL give for (probe-file :name
> "test.lisp" :type "0")?

I'm sure you meant this:
* (probe-file (make-pathname :name "test.lisp" :type "0"))
#p"/usr/home/blitz/src/test.lisp.0"

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?

[Julian Stecklina]

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

[...]

> It is a shame to have lost the many good features of the old operating
> systems.
>
> It is further a shame to have lost the memory of those things.

[...]

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

[Nils Goesche]

In article <sfw3czt...@shell01.TheWorld.com>, Kent M Pitman wrote:

> The logical pathname abstraction creates a virtual file system, just
> as a Java creates a virtual machine. You start with something
> physical and you layer up a new abstraction.

[snip]

> From there, for the most part, you do the same things with logical
> pathnames you do with other pathnames. You do stuff like
>
> (with-open-file (x "ZING:FOO1;BAR2;FOO.LISP")
> ...)
>
> to open such a file, for example.

I think this is the key. I was thinking all night about what the
problem with pathnames is (I find them hard to grasp, too), and
my conclusion was that the problem all expositions I know have
is that they start with make-pathname etc. and /not/ with logical
pathnames. One should tell people: First, start writing filenames
in upper case (for such and such reasons). Or in lower case, if
you want a file named `README'. This is something that looks
easy to do, I think everybody can understand that, can immediately
use something and it looks good, an immediate progress. From there,
the pathname structure looks only like a cool feature to parse
and manipulate those things. The usual approach, starting with
pathnames, looks different to a beginner:

(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.

[Christopher Browne]

In the last exciting episode, Kent M Pitman <pit...@world.std.com> wrote::

> e...@agharta.de (Dr. Edmund Weitz) writes:
>> CG-USER(7): (pathname-version *my-pathname*)
>> :UNSPECIFIC

> That's normal for most modern operating systems (Windows, Linux,
> Mac). I think there's some ISO file system (ISO9000?) that's still
> "current" and has versions, and there are a number of older
> operating systems with versions.

That would be ISO 9660, used for CD-ROMs.

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...

>> 2. LispWorks:

>>
>> CL-USER 18 > (defparameter *my-namestring* "c:\\Documents and Settings\\Administrator\\Desktop\\Love-letter-for-you.txt.vbs")
>> *MY-NAMESTRING*
>> CL-USER 19 > (probe-file *my-namestring*)
>> #P"c:/Documents and Settings/Administrator/Desktop/Love-letter-for-you.txt.vbs"
>> CL-USER 20 > (type-of *)
>> PATHNAME
>> CL-USER 21 > (defparameter *my-pathname* (pathname *my-namestring*))
>> *MY-PATHNAME*
>> CL-USER 22 > (pathname-host *my-pathname*)
>> "c"

> Again, I'd prefer uppercase here. It saddens me that they think
> this is a host, because I think of it as a device. But in their
> defense, if you think of it as a designator for an underlying object
> with more structure, it's true that C: might denote a FAT file
> system while D: might be NTFS. As such, since a "host" is usually
> structured and a device usually only "named", it does make some
> sense that the host would encapsulate this info.

>> Disclaimer: Apart from some faint memories of systems like NOS/VE (was

>> that from DEC? I can't remember), TOS, CP/M, I've only
>> dealt with the systems that seem to be in wide-spread use
>> today - Unix, Mac, DOS/Windows. I understand that
>> historically CL had to cope with many other filesystems
>> that I've never used personally and I regard it as an
>> heroic effort to even try to invent an abstract concept
>> that applies to all of them. I just wonder if it wasn't
>> futile.

> I still use my Lisp Machine today to debug certain kinds of code,
> and don't personally regard this as futile. No personal slight
> intended, but I also tend to think as a general concept that it's
> the height of arrogance for mankind, in general, to use words like
> "modern" as if these were stable. Increasingly, as I see things
> change in the world, I prefer the term "contemporary" because it
> acknowledges that today's "modern" will be tomorrow's
> "old-fashioned". Just becuase we have Unix, Mac, Windows today
> doesn't mean we'll be stuck without versioning forever. I hope
> someone will have the good sense to invent it. Certainly it's there
> for the ISO file system. CL is not an attempt to be "of the
> moment", it is an attempt to be "timeless".

I would suggest the term "latter day" somewhat paralleling the Lord of

[Julian Stecklina]

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

[...]

> I'd like to pursue this discussion to the point

> of discovering the conceptual roadblock that I am not seeing but you are
> having.

[...]

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. :)

[Raymond Toy]

>>>>> "Julian" == Julian Stecklina <der_j...@web.de> writes:

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

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.

Ray

[Christophe Rhodes]

Nils Goesche <car...@cartan.de> writes:

[ snippety snip ]

> One should tell people: First, start writing filenames
> in upper case (for such and such reasons). Or in lower case, if
> you want a file named `README'.

Except that my understanding was that this was unportable in logical
pathnames; that is, that #p"LHOST:README" and #p"LHOST:readme"
referred to the same pathname for a logical host LHOST.

[Nils Goesche]

In article <sq7kp5x...@cam.ac.uk>, Christophe Rhodes wrote:
> Nils Goesche <car...@cartan.de> writes:
>
> [ snippety snip ]
>
>> One should tell people: First, start writing filenames
>> in upper case (for such and such reasons). Or in lower case, if
>> you want a file named `README'.
>
> Except that my understanding was that this was unportable in logical
> pathnames; that is, that #p"LHOST:README" and #p"LHOST:readme"
> referred to the same pathname for a logical host LHOST.

Ok, forget the case thing, then. I guess I'll need another night to
figure it out ;-|

[Christophe Rhodes]

Nils Goesche <car...@cartan.de> writes:

> In article <sq7kp5x...@cam.ac.uk>, Christophe Rhodes wrote:
> > Nils Goesche <car...@cartan.de> writes:
> >
> > [ snippety snip ]
> >
> >> One should tell people: First, start writing filenames
> >> in upper case (for such and such reasons). Or in lower case, if
> >> you want a file named `README'.
> >
> > Except that my understanding was that this was unportable in logical
> > pathnames; that is, that #p"LHOST:README" and #p"LHOST:readme"
> > referred to the same pathname for a logical host LHOST.
>
> Ok, forget the case thing, then. I guess I'll need another night to
> figure it out ;-|

Just in case anyone's wondering about where I get this from, it's
section 19.3.1.1.7, or
<URL:http://www.xanalys.com/software_tools/reference/HyperSpec/Body/19_caag.htm>
in the brave new HyperSpec.

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 :)

[Tim Bradshaw]

* I wrote:
[stuff about logical pathnames]

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.

--tim

[Marco Antoniotti]

Tim Bradshaw <t...@cley.com> writes:

> * I wrote:
> [stuff about logical pathnames]
>
> 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.

This is exactly the approach taken in (shameless plug)
CL-CONFIGURATION. :)

Cheers

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

[Kent M Pitman]

Nils Goesche <car...@cartan.de> writes:

> In article <sq7kp5x...@cam.ac.uk>, Christophe Rhodes wrote:
> > Nils Goesche <car...@cartan.de> writes:
> >
> > [ snippety snip ]
> >
> >> One should tell people: First, start writing filenames
> >> in upper case (for such and such reasons). Or in lower case, if
> >> you want a file named `README'.
> >
> > Except that my understanding was that this was unportable in logical
> > pathnames; that is, that #p"LHOST:README" and #p"LHOST:readme"
> > referred to the same pathname for a logical host LHOST.
>
> Ok, forget the case thing, then. I guess I'll need another night to
> figure it out ;-|

We're making progress here. Here's another probably non-obvious factoid:

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.

The purpose of the logical pathname is _not_ to allow you to refer to
all pathnames, but rather to allow you to manipulate _enough_
pathnames that you can use it to talk about the filenames you need to
load to build a system and the pathnames you need to load to
manipulate that system's wired data. So you should expect to see
logical pathnames used in calls to LOAD to construct a system and to
read and write data finitely enumerable data files of the system, but
you should not expect this datatype to be powerful enough to
accomodate arbitrary filenames of every host operating system. It
tries to steer you clear of those. It is not really intended that you
expose it to users who want to answer a "type in a filename" query,
etc.

[Kent M Pitman]

Julian Stecklina <der_j...@web.de> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
>
> [...]
>
> > I'd like to pursue this discussion to the point
> > of discovering the conceptual roadblock that I am not seeing but you are
> > having.
>
> [...]
>
> 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. :)

I should also emphasize that I'm extra-testy about the pathnames
chapter because I have many times remarked that it was at the top of
my list to rewrite in clearer form if I'd had more time. We were
resource-limited in the work on ANSI CL, and at some point had to just
call it quits and use what we had.

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.

The Lisp Machine design, from which the CL design was directly
created, was in almost every way a more robust design than CL was, and
people stubbornly refused to vote to borrow from Nike's lead and "Just
use it". The only couple of cases where the CL pathname system was
improved by CL's voting was to require :absolute at the head of
absolute pathnames (LispM just treated a missing :relative as
absolute, and that led to periodic problems) and the decision to let
logical pathnames expand to other logical pathnames (which I think is
just right and proper). In almost all other cases, the committee
either declined to fix a LispM bug or opted not to take the part of
the LispM system that would have fixed an easy-to-anticipiate major
gap in functionality.

[Nils Goesche]

In article <sfwofih...@shell01.TheWorld.com>, Kent M Pitman wrote:
> Nils Goesche <car...@cartan.de> writes:
>
>> In article <sq7kp5x...@cam.ac.uk>, Christophe Rhodes wrote:
>> > Nils Goesche <car...@cartan.de> writes:
>> >
>> > [ snippety snip ]
>> >
>> >> One should tell people: First, start writing filenames
>> >> in upper case (for such and such reasons). Or in lower case, if
>> >> you want a file named `README'.
>> >
>> > Except that my understanding was that this was unportable in logical
>> > pathnames; that is, that #p"LHOST:README" and #p"LHOST:readme"
>> > referred to the same pathname for a logical host LHOST.
>>
>> Ok, forget the case thing, then. I guess I'll need another night to
>> figure it out ;-|
>
> We're making progress here. Here's another probably non-obvious factoid:

Seems so. Thanks for the explanation!

> 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.
>
> The purpose of the logical pathname is _not_ to allow you to refer to
> all pathnames, but rather to allow you to manipulate _enough_
> pathnames that you can use it to talk about the filenames you need to
> load to build a system and the pathnames you need to load to
> manipulate that system's wired data. So you should expect to see
> logical pathnames used in calls to LOAD to construct a system and to
> read and write data finitely enumerable data files of the system, but
> you should not expect this datatype to be powerful enough to
> accomodate arbitrary filenames of every host operating system. It
> tries to steer you clear of those. It is not really intended that you
> expose it to users who want to answer a "type in a filename" query,
> etc.

That comes quite close to what I thought how it worked. The only
difference seems to be that I assumed that all those examples
were in upper case because they were mapped onto actual file names
in a manner similar to the :case :common argument of make-pathname.
That seemed to be no problem, at first. But one could indeed
introduce problems by having one file named README and another one
named Readme, and the case insensitivity of logical pathnames
helps to prevent this. Right?

[Erann Gat]

In article <sfw3czt...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> The logical pathname abstraction creates a virtual file system, just
> as a Java creates a virtual machine. You start with something
> physical and you layer up a new abstraction.
>
> Logical pathnames refer to files on a logical host. A logical host
> named "ZING" is marked by "ZING:".
>
> In the logical host's file system are directories "FOO1", "FOO2",
> etc. that are referred to as "FOO1;" , "FOO2;", etc. If you want
> subdirs "BAR1", "BAR2", etc. of "FOO1;" you write "FOO1;BAR1;" etc.
>
> Files in a file directory have a name part, a type part, and a version
> part. "FOO.LISP" has a name and type. "FOO.LISP.3" has a name and type
> and version.
>
> From there, for the most part, you do the same things with logical
> pathnames you do with other pathnames. You do stuff like

[SNIP]

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.

E.

[Daniel Barlow]

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

> Logical pathnames refer to files on a logical host. A logical host
> named "ZING" is marked by "ZING:".
>
> In the logical host's file system are directories "FOO1", "FOO2",
> etc. that are referred to as "FOO1;" , "FOO2;", etc. If you want
> subdirs "BAR1", "BAR2", etc. of "FOO1;" you write "FOO1;BAR1;" etc.

Do you mean here that "FOO1;BAR1;" is a namestring for the relative
logical pathname with :directory (:relative "FOO1" "BAR1"), or are you
just writing parts of namestrings that are not syntactically valid on
their own?

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

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

[Erik Naggum]

* Erik Naggum
> The obvious eludes explanation.

* Kenny Tilton

| Not to a good teacher.

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.

///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.

[Christopher Browne]

In an attempt to throw the authorities off his trail, Erik Naggum <er...@naggum.net> transmitted:

> 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 :).

Oh, my, that gives a _completely_ different take on "pathological"...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/
"A cynic is a man who knows the price of everything, and the value of
nothing." -- Oscar Wilde

[Kent M Pitman]

Nils Goesche <car...@cartan.de> writes:

> That comes quite close to what I thought how it worked. The only
> difference seems to be that I assumed that all those examples
> were in upper case because they were mapped onto actual file names
> in a manner similar to the :case :common argument of make-pathname.

No, they're in uppercase because I visually like them that way. I think
of uppercase as the neutral case (because in CL it is defined that way)
and I like to remind myself visually that the neutral case is the only
case available. Were I to mix cases in the example, it might wrongly imply
that there was a difference between them. Heh.... Can't win.

> That seemed to be no problem, at first. But one could indeed
> introduce problems by having one file named README and another one
> named Readme, and the case insensitivity of logical pathnames
> helps to prevent this. Right?

Well, there are two issues here. Yes, the case-insensitivity keeps you
from making two files that differ only in case. That's an intentional
design feature. But there's a stupid irritating trick in Unix that one
puts something in uppercase to force it to list in a directory at the head
because Unix thinks that the letter ordering is A...Za...z rather than
AaBbCc... This is, unfortunately, an issue of exploiting case. A conseuence
is that one cannot make a system delivered in logical pathnames that puts
a README.txt file at the head of a directory. You will get a readme.txt
file lost in the middle of the other files. To do the "non-standard case"
trick, you must use real pathnames.

[Kent M Pitman]

g...@jpl.nasa.gov (Erann Gat) writes:

> 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 way the Lisp Machine had done it was best. It had something called
the "host colon" convention that said that the first colon always delimited
a host, and that subsequent colons were host-specific syntax. One could
omit a host (allowing it to default) by starting with a colon, as in
":foo:bar".

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

which actually meant "go to the INTERNET name system, use the name 1.2.3.4,
then get the resulting host and ask for its FEP0 file system and parse the
rest using that notation" ... so I suppose the VAX stuff could have been
squeezed in thus, by making the Lispy syntax different than the native syntax,
or else could have been accomodated by doing MYVAX:A::B::CC::... and treating
it all as host-specific.

[Kent M Pitman]

Daniel Barlow <d...@telent.net> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > Logical pathnames refer to files on a logical host. A logical host
> > named "ZING" is marked by "ZING:".
> >
> > In the logical host's file system are directories "FOO1", "FOO2",
> > etc. that are referred to as "FOO1;" , "FOO2;", etc. If you want
> > subdirs "BAR1", "BAR2", etc. of "FOO1;" you write "FOO1;BAR1;" etc.
>
> Do you mean here that "FOO1;BAR1;" is a namestring for the relative
> logical pathname with :directory (:relative "FOO1" "BAR1"), or are you
> just writing parts of namestrings that are not syntactically valid on
> their own?

No. FOO1;BAR1; is the same as >foo>bar> on multics. It designates a
directory. It's valid to have a directory pathname in isolation, so it
is valid on its own. But it's not valid in Unix to have a name /foo/bar/
that means different than /foo/bar, so you're more asking about a
Unix deficiency.

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.

> 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

FOO;BAR; is absolute

;FOO;BAR; is relative.

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

N/A, see above

> (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?

IMO, no one should ever assume that (:ABSOLUTE) exists on a logical pathname.
"BAZ.LISP" has an unsupplied directory and needs one.

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.

> 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?

Ick. I wouldn't want you to. You risk having someone think the pathname
is filled. Consider that

(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.

Does this help or just make things muddier?

[Eduardo Muñoz]

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

> 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.

Excuse me if I'm being a bit naïve but...

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 :)

--

Eduardo Muñoz

[Harald Hanche-Olsen]

+ Kenny Tilton <kti...@nyc.rr.com>:

| Kent M Pitman wrote:
| > Kenny Tilton <kti...@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.

--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?

[Erik Naggum]

* "Eduardo Muñoz" <e...@jet.es>

| 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.

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.)

[Tim Bradshaw]

* Eduardo Muñoz wrote:
> 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.

While I'd love to see a book by KMP, I don't see what has got
basically easier about writing a book since the invention of good text
editors. *Publishing* may be easier (especially if you don't want to
get paid much/at all) but you still have to write hundreds of pages of
high-quality text, which is the main barrier...

--tim

[Dr. Edmund Weitz]

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

[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.

> The thing the creators of the standard made of it was that if the
> community ever cared enough, it could make layered standards. Then
> vendors who wanted to could adhere to such standards, and vendors
> who didn't could ignore them.

Just out of curiosity: Did such layered standards ever happen? I
suppose the answer is no. At least I've never heard of one since I
started reading c.l.l.

> > Assume I'm writing an application with ACL for Windows but I want
> > it to be portable to LispWorks and CormanLisp as
> > well. Furthermore, I might want to target the Linux market with
> > the same application later on. It looks like I have to resort to
> > namestrings (which is as unportable as it could be) if I want to
> > specify the exact location of a file in the filesystem.
>
> This is a HUGE leap from what you said above. Why would you say
> that??
>
> I don't agree at all with this conclusion.

Hmm, maybe I was to rash with my conclusion. I should add here that I
don't have a specific application in mind. If I had to use file system
functions in the past, I just used namestrings because I wrote those
apps for learning the language and didn't care about portability. My
asking things about pathnames now is also just based upon my desire to
learn what they're for. Currently, I'm just toying around with them
and ask questions while a month ago I would have just eschwed them
completely 'cause I thought I would never get it.

> I'm not going to make up examples here without a framework of a real
> program. It is definitely not the case that one can just work from
> pathnames to an arbitrary algebra of ideas that works for all
> operating systems everywhere. There are too many rough edges. But
> most of the common cases do work quite predictably, and I don't
> understand why you would think otherwise. I need examples of what
> you are saying doesn't work.

No, I wasn't intending to say that something doesn't work. To the
contrary, I was looking for examples how pathnames may work because I
couldn't imagine them myself.

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.)

> > Disclaimer: Apart from some faint memories of systems like NOS/VE (was
> > that from DEC? I can't remember), TOS, CP/M, I've only
> > dealt with the systems that seem to be in wide-spread use
> > today - Unix, Mac, DOS/Windows. I understand that
> > historically CL had to cope with many other filesystems
> > that I've never used personally and I regard it as an
> > heroic effort to even try to invent an abstract concept
> > that applies to all of them. I just wonder if it wasn't
> > futile.
>
> I still use my Lisp Machine today to debug certain kinds of code,
> and don't personally regard this as futile. No personal slight
> intended, but I also tend to think as a general concept that it's
> the height of arrogance for mankind, in general, to use words like
> "modern" as if these were stable. Increasingly, as I see things
> change in the world, I prefer the term "contemporary" because it
> acknowledges that today's "modern" will be tomorrow's
> "old-fashioned". Just becuase we have Unix, Mac, Windows today
> doesn't mean we'll be stuck without versioning forever. I hope
> someone will have the good sense to invent it. Certainly it's there
> for the ISO file system. CL is not an attempt to be "of the
> moment", it is an attempt to be "timeless".

If you understood my paragraph above as promoting "modern" concepts
versus proven solutions like CL this must be due to my not being a
native speaker. I _do_ value solutions which try to be timeless and I
hate to see them losing against marketing hype almost always. To give
an example: When doing photography, I always use _very_ old Leica
rangefinder cameras, Kodak b/w films from the fifties and good old
French baryt paper. I cannot understand why people prefer all those
pesky "modern" cameras and materials, especially the digital ones. But
this is a personal luxury, and I'm doing this as my hobby, while
programming is my means of feeding my family. I'd love to know more
about Lisp Machines and other things that I never came across. But my
spare time is limited and I guess I'll have to cope with Unix, Mac,
Windows for the next couple of years... :(

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

Edi.

--

Dr. Edmund Weitz
Hamburg
Germany

The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>

[Gareth McCaughan]

Kenny Tilton wrote:

[Kent Pitman:]

> > have once said about thesis writing: If I'd had more time, I would have
> > written less.

[Kenny:]

> 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'm fairly sure it was Pascal. But yes, it was at the end of a letter.

--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc

[Dr. Edmund Weitz]

Tim Bradshaw <t...@cley.com> writes:

> Well one thing you missed is that Windows has at least one other
> type of pathname, namely UNC (?) paths - the things that looks like
> \\host\share\path...\file.type. Any system that runs on Windows
> needs to cope with these things as well as normal physical paths, I
> think.

You're right, I forgot about it. It shows that I don't use Windows
that often I guess.

[Kent M Pitman]

Erik Naggum <er...@naggum.net> writes:

> * "Eduardo Muñoz" <e...@jet.es>
> | 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.
>
> 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.

This part is definitely on target.

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 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.

This part is also right, but the underscoring of "official" is so
subtle it might not have sunk in. Let me expand: It is possible for
me or anyone to create unofficial remarks that are our personal
opinions about what we wish. We simply must not say "the standard
says...". We can say "I wish the standard had said..." or "I suggest
the following style as a way of filling in gaps in the standard..."

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.

> | 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.

Well, I think the danger is all a function of presentation, but it's surely
true that a legally and socially safe presentation might lose some of the
definitiveness that is perhaps being suggested here.

> | 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.

Heh.

> 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.)

Not lost on me.

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.

Further, when we voted to approve, "I observed that" and "I recall
that" we said over and over explicitly to everyone: Once we vote yes,
it will erase all the cleanup writeups. Truth will from then on be
judged not by what we intended, but what we wrote (and more to the
point: what I typed, whether or not I transcribed or edited
accurately) and that people had better be darn sure that they were
willing to stand not just by all the little votes leading up but by
the actual words we wrote... This goes back to the discussion of Sir
Thomas More I made in another thread yesterday, on the philosophy of
the meaning of words and language. But I won't repeat myself on that
so soon; dredge it up in DejaNews (a.k.a groups.google.com) if you
care.

[Eduardo Muñoz]

Tim Bradshaw <t...@cley.com> writes:

> * Eduardo Muñoz wrote:
> > Writing a book these days isn't big bussines but

[...]

> While I'd love to see a book by KMP, I don't see what has got
> basically easier about writing a book since the invention of good text
> editors. *Publishing* may be easier (especially if you don't want to
> get paid much/at all) but you still have to write hundreds of pages of
> high-quality text, which is the main barrier...

I was talking about money, not about easyness :)

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

--

Eduardo Muñoz

[Kent M Pitman]

e...@agharta.de (Dr. Edmund Weitz) writes:

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

> > The thing the creators of the standard made of it was that if the
> > community ever cared enough, it could make layered standards. Then
> > vendors who wanted to could adhere to such standards, and vendors
> > who didn't could ignore them.
>
> Just out of curiosity: Did such layered standards ever happen? I
> suppose the answer is no. At least I've never heard of one since I
> started reading c.l.l.

No. They tried to happen, but no one wanted them.

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.

> 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

As a string. End-users don't care about Lisp datatypes.

> 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).

Right. This is where you use structured tools for merging so you don't
screw up the merging by ad hoc string operations of your own

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

> 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.

Right.

> I could then convert this namestring to a pathname

This will be done implicitly by pathname operations. For efficiency, it's
sometimes useful to do it early to keep it from being done over and over.
But it's not much an issue. You can just carry it around as a string and
still do all the pathname operations on it.

> 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.

Again done by MAKE-PATHNAME or MERGE-PATHNAMES.

> 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.

Don't do this as a string. And pathnames have no notion of "appending".
You mean you could do MAKE-PATHNAME (with :defaults) or MERGE-PATHAMES.

> Now that I think of it this really sounds more portable and elegant
> than fiddling with the namestrings themselves.

Yes.

> 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... :)

Yes.

> Is that the way pathnames are intended to be used?

Yes.

> (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.)

On Tops-20, a "device" was a kind of component. They were like C: and
D: on MS-DOS and I prefer to think of those as "devices". So if you
do, in Tops-20, "PS:<FOO.BAR.BAZ>FILE.LISP.13" you mean "device PS"
(kinda like "C:" since PS meant "primary structure"), directory
(:ABSOLUTE "FOO" "BAR" "BAZ"), name "FILE", type "LISP", version 13.
Note that "SS:<FOO.BAR.BAZ>" or "SECOND:<FOO.BAR.BAZ>" were often
unrelated directories. And also that it could be that device: was not
just a primitive file structure but a search list (kind of like $PATH)
so that it would find the first of several structures. This is all
trivia about Tops-20 I'm telling you. It had nothing to do with CL.
But CL's pathname system accomodates this. OZ:PS:<KMP>LISP.INI might
have been my init file on the primary file system of the host OZ, as
referred to by the Lisp Machine with its "host colon" convention that the
first colon was the host and the remaining colons were host specific.

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)

A good rule of thumb, I claim, is to always use :case :common.
I can't stand that it is not the default, but since it is, you must
always make it explicit. And don't get lazy about using it on the
accessors, or you will compose stupid-looking filenames. The algebra
decomposing and recomposing filenames only comes out right if you
consistently use :case :common everywhere.

[Julian Stecklina]

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

[...]

> Well, there are two issues here. Yes, the case-insensitivity keeps you
> from making two files that differ only in case. That's an intentional
> design feature. But there's a stupid irritating trick in Unix that one
> puts something in uppercase to force it to list in a directory at the head
> because Unix thinks that the letter ordering is A...Za...z rather than
> AaBbCc... This is, unfortunately, an issue of exploiting case. A conseuence
> is that one cannot make a system delivered in logical pathnames that puts
> a README.txt file at the head of a directory. You will get a readme.txt
> file lost in the middle of the other files. To do the "non-standard case"
> trick, you must use real pathnames.

What's the whole point about case-sensitivity in file systems anyway?
Isn't it plain stupid to allow readme.txt and Readme.txt to coexist?
Why do I have to remember/find out/etc the case of a filename to use
it? This seems error prone to me. The same applies to case-sensitivity
in other areas (just think of certain programming languages... btw:
Can you still disable it with Borland C++ compilers?)

Regards,
Julian

--
Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/

[Kent M Pitman]

Julian Stecklina <der_j...@web.de> writes:

> ...

> What's the whole point about case-sensitivity in file systems anyway?
> Isn't it plain stupid to allow readme.txt and Readme.txt to coexist?
> Why do I have to remember/find out/etc the case of a filename to use
> it? This seems error prone to me. The same applies to case-sensitivity
> in other areas (just think of certain programming languages... btw:
> Can you still disable it with Borland C++ compilers?)

We have sometimes discussed whether the mere name Lisp holds Lisp back.
People think they know it from what it was years ago.

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....)

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.

[Erik Naggum]

* Kent M Pitman

| We have sometimes discussed whether the mere name Lisp holds Lisp back.
| People think they know it from what it was years ago.

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...

[Stefan Schmiedl]

On Fri, 22 Feb 2002 23:36:43 GMT,

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

> e...@agharta.de (Dr. Edmund Weitz) writes:
>
>> 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... :)
>
> Yes.
>
>> Is that the way pathnames are intended to be used?
>
> Yes.
>
>> (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.)
>
> On Tops-20, a "device" was a kind of component. They were like C: and
> D: on MS-DOS and I prefer to think of those as "devices". So if you
> do, in Tops-20, "PS:<FOO.BAR.BAZ>FILE.LISP.13" you mean "device PS"
> (kinda like "C:" since PS meant "primary structure"), directory
> (:ABSOLUTE "FOO" "BAR" "BAZ"), name "FILE", type "LISP", version 13.

> ........

> 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.

hmm.... would it be possible to use pathnames for database access?
the device would be the database engine, top level "directories"
databases, second level "directories" tables and views, and third level
entries would be records accessible by some primary key.

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

s.

[Tim Bradshaw]

* Eduardo Muñoz wrote:

> I was talking about money, not about easyness :)

Oops, sorry my mistake. Your phrasing now makes a lot more sense to
me!

--tim

[Pierre R. Mai]

Tim Bradshaw <t...@cley.com> writes:

> * Edmund Weitz wrote:
>
> > Disclaimer: Apart from some faint memories of systems like NOS/VE (was
> > that from DEC? I can't remember), TOS, CP/M, I've only
> > dealt with the systems that seem to be in wide-spread use
> > today - Unix, Mac, DOS/Windows. I understand that
> > historically CL had to cope with many other filesystems
> > that I've never used personally and I regard it as an
> > heroic effort to even try to invent an abstract concept
> > that applies to all of them. I just wonder if it wasn't
> > futile.
>

> Well one thing you missed is that Windows has at least one other type
> of pathname, namely UNC (?) paths - the things that looks like
> \\host\share\path...\file.type. Any system that runs on Windows needs
> to cope with these things as well as normal physical paths, I think.

Actually, last time I looked, there were many applications that didn't
anticipate such pathnames, and hence didn't work, or didn't work
correctly with those. In those cases you need to make use of the OS's
capability to map such pathnames to "drive letters", which can then be
used by the application at hand.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein

[Gene Michael Stover]

Julian Stecklina wrote:

> I searched ANSI Common Lisp and On Lisp by Paul Graham, but both seem
> to ignore the topic of logical pathnames or pathnames in general. The
> Hyperspec is a little vague about that topic and I could not find some
> kind of tutorials. CLiki and the Cookbook do not provide any
> information either.
>
> Can anybody help?

For what it's worth, I'm expecting a beginner's level
article about logical pathnames for the first issue of Yadda
Lambda magazine (which I announced in another thread here
last night.) That won't be until April, though.

gene

[Tim Bradshaw]

* Pierre R Mai wrote:
> Actually, last time I looked, there were many applications that didn't
> anticipate such pathnames, and hence didn't work, or didn't work
> correctly with those. In those cases you need to make use of the OS's
> capability to map such pathnames to "drive letters", which can then be
> used by the application at hand.

Fortunately the lisp system I use isn't one (:-).

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.

--tim

[Dorai Sitaram]

In article <32234172...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:
> 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.

... and allowing Scheme to position itself as a
healthy, "low-sodium" Lisp.

--d

[Erik Naggum]

* Dorai Sitaram

| ... and allowing Scheme to position itself as a healthy, "low-sodium"
| Lisp.

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.

[Gareth McCaughan]

Dorai Sitaram wrote:

No, clearly the low-sodium one would be KCL. Er, I mean
KCl.

[Martin Simmons]

"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfw3czt...@shell01.TheWorld.com...

> IMO, no one should ever assume that (:ABSOLUTE) exists on a logical pathname.
> "BAZ.LISP" has an unsupplied directory and needs one.

Do you think this was a deliberate restriction of logical pathnames namestrings
or just an oversight? Should pathnames such as

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

be printable?

> Ick. I wouldn't want you to. You risk having someone think the pathname
> is filled. Consider that
>
> (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.

Actually, I don't think nil will grab the dir from foo either -- only omitting
:directory will do that.
--
Martin Simmons, Xanalys Software Tools
zne...@xanalys.com
rot13 to reply

[Kent M Pitman]

"Martin Simmons" <zne...@xanalys.com> writes:

> "Kent M Pitman" <pit...@world.std.com> wrote in message
> news:sfw3czt...@shell01.TheWorld.com...
>
> > IMO, no one should ever assume that (:ABSOLUTE) exists on a
> > logical pathname. "BAZ.LISP" has an unsupplied directory and
> > needs one.
>
> Do you think this was a deliberate restriction of logical pathnames
> namestrings or just an oversight? Should pathnames such as
>
> (make-pathname :host "SYS" :directory '(:absolute) :name "FOO")
>
> be printable?

Well, as discussed ad nauseum, I don't make the rules. But personally, I
don't think it has a printed representation. Whether that means an error
should be signaled or a system-specific heuristic like
SYS:ROOT-DIRECTORY;FOO
should be printed is a little less clear. I do think there is a problem.

> > Ick. I wouldn't want you to. You risk having someone think the pathname
> > is filled. Consider that
> >
> > (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.
>
> Actually, I don't think nil will grab the dir from foo either --
> only omitting :directory will do that.

Oh, sorry. Yes, you're right, of course.

[Marco Antoniotti]

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

> "Martin Simmons" <zne...@xanalys.com> writes:
>
> > "Kent M Pitman" <pit...@world.std.com> wrote in message
> > news:sfw3czt...@shell01.TheWorld.com...
> >
> > > IMO, no one should ever assume that (:ABSOLUTE) exists on a
> > > logical pathname. "BAZ.LISP" has an unsupplied directory and
> > > needs one.
> >
> > Do you think this was a deliberate restriction of logical pathnames
> > namestrings or just an oversight? Should pathnames such as
> >
> > (make-pathname :host "SYS" :directory '(:absolute) :name "FOO")
> >
> > be printable?
>
> Well, as discussed ad nauseum, I don't make the rules. But personally, I
> don't think it has a printed representation. Whether that means an error
> should be signaled or a system-specific heuristic like
> SYS:ROOT-DIRECTORY;FOO
> should be printed is a little less clear. I do think there is a
> problem.

Well, what is your *opinion* about what the following should do on your
regular UNIX system?

(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

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

[Marco Antoniotti]

Marco Antoniotti <mar...@cs.nyu.edu> writes:

PS. Note also the convient defaulting form of the call to
PARSE-NAMESTRING.

[Pekka P. Pirinen]

Nils Goesche <car...@cartan.de> writes:
> [...] 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).
> [...] Later on, I tried to explain it to beginners, too, more and
> more slowly. But noone ever got it.

Maybe the beer had something to do with it.

I have this image of Nils scribbling on a beer mat already densely
covered with stars of vectors radiating into all directions from a
point: "You see, if we take functions that have a zero here... and the
derivative has a zero also... we can form a dual space out of
them... and the functions... with a zero... at this point... here..."
The beginner pushes his face into the diagram, studying it minutely,
and says: "Wow, if you squint your eyes, you can see the vectors
radiating in _three_ dimensions!"
--
Pekka P. Pirinen
"If you don't look after knowledge, it goes away."
- Terry Pratchett, The Carpet People

[Tim Bradshaw]

* 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!

--tim

[Nils Goesche]

Hehe :-) I always had the impression that beer and mathematics
don't disturb each other very much. When I later read again what
I wrote days ago in some bar at five in the morning it always still
makes sense. The group around Stefan Banach, who invented large parts
of functional analysis in the thirties, always met in the same bar.
They developed most of the theory in there. They used to scribble
notes and formulae on the table cloth, which the waiters didn't like,
so the waiters began to always put a large sheet of paper onto their
favorite table. Those were collected, and can now be seen in some
museum in poland. Stefan Banach was known to outdrink everyone else.

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."

PGP key ID 0x42B32FC9

[Harald Hanche-Olsen]

+ Tim Bradshaw <t...@tfeb.org>:

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.

--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?

[Nils Goesche]

In article <pcor8n6...@thoth.math.ntnu.no>, Harald Hanche-Olsen wrote:
> + Tim Bradshaw <t...@tfeb.org>:
>
>| * 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:

[snip derivations method]

> 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.

The hard part with this method is that you must be pretty careful
along the way to make sure everything is correct. For instance,
one problem that is very hard to spot: Is the ``tangent space''
you get in this way actually of finite dimension? Surprise: No,
it isn't, unless the manifold is at least C^\infty.

> 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.

I hope I won't get killed for getting so off-topic, but people
keep asking me, by Email, too, and maybe someone will be glad if
he finds this thread googling sometime in the future.

So, here it goes:

Let M be a n-dimensional C^1 manifold, p \in M. We want to
define the tangent space T_p M at p.

First consider the set of pairs (Q,f) where Q is an open
neighborhood of p and f a C^1 function defined on Q. Declare two
pairs (Q_1, f_1), (Q_2, f_2) to be ``equivalent'' iff there
exists an open neighborhood R of p which is contained in both Q_1
and Q_2, such that f_1 and f_2 restricted to R coincide. The
factor space by this equivalence relation is called ``the space
of germs of functions'' at p. It is naturally a vector space,
let's call it F_p. (I guess you know that construction)

If you have a C^1 function f defined in a neighborhood of p, and
express it in some coordinate system as f(u^1, ..., u^n), such that
(0, ..., 0) are the coordinates of p, let's call f ``stationary'' at p
iff all partial derivatives of f(u^1, ..., u^n) vanish at 0. It is
easy to see that this gives rise to a vector subspace of F_p
consisting of ``stationary function germs'', because this vanishing of
the ``gradient'' is in fact _independent_ of the choice of
coordinates, and obviously doesn't care if we make the neighborhood of
p, where f is defined, smaller. Let's call this subspace kern grad
(there is no real gradient mapping, but this name makes the whole
construction easier to remember).

Now, define T^\asterisk_p M, to be the vector quotient space
F_p / kern grad. The natural projection

d : F_p -> T^\asterisk_p M

is called ``d'' :-)

A system of coordinates (u^1,...,u^n), naturally defines n germs
at p, [u^1], ..., [u^n], which we will, somewhat sloppily, also
denote by u^1, ..., u^n. The images of those under d are thus
called

du^1, ..., du^n

(Now isn't that wonderful? :-)

It is easy to see that du^1,...,du^n are a basis for the vector
space T^asterisk_p M.

Define the ``tangent space'' of M at p, denoted T_p M, to be the
vector dual space of T^asterisk_p M. The dual basis of
du^1, ..., du^n is denoted

\partial / \partial u^1, ..., \partial / \partial u^n.

=======

Now, that looks pretty long, but what you have to write down is so
little that it fits onto a beer mat, you only have to explain some
pictures and arrows. No computations at all. And it works even
for C^1 manifolds.

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

PGP key ID 0xC66D6E6F

[Harald Hanche-Olsen]

+ Nils Goesche <n...@cartan.de>:

| Surprise: No, it isn't, unless the manifold is at least C^\infty.

I was hoping you wouldn't mention that. 8-)

[Andreas Eder]

e...@agharta.de (Dr. Edmund Weitz) writes:

> Disclaimer: Apart from some faint memories of systems like NOS/VE (was
> that from DEC? I can't remember)

No, NOS/VE was an OS fpr the CDC Cyber machines.

Andreas
--
Wherever I lay my .emacs, there愀 my $HOME.

[Dr. Edmund Weitz]

Andreas Eder <Andrea...@t-online.de> writes:

> e...@agharta.de (Dr. Edmund Weitz) writes:
>
> > Disclaimer: Apart from some faint memories of systems like NOS/VE (was
> > that from DEC? I can't remember)
>
> No, NOS/VE was an OS fpr the CDC Cyber machines.

Thanks for the info. I remember working with it in my first two years
at the university, I even wrote a minimal internal messaging system
for our seminar on top of it, but I can't remember any details. I'm
glad the I can still remember the name at all... :)

Edi.

--

Dr. Edmund Weitz
Hamburg
Germany

The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>

[Tord Kallqvist Romstad]

Nils Goesche <n...@cartan.de> writes:

<Huge snip>

> Now, that looks pretty long, but what you have to write down is so
> little that it fits onto a beer mat, you only have to explain some
> pictures and arrows. No computations at all. And it works even
> for C^1 manifolds.

Cute, but the definition is perhaps not as unusual as you think. This
is more or less precisely how the tangent space is defined in most
elementary textbooks on _algebraic_ geometry.

--
Tord Romstad

[Nils Goesche]

In article <gqkg03f...@janus.uio.no>, Tord Kallqvist Romstad wrote:

> Cute, but the definition is perhaps not as unusual as you think. This
> is more or less precisely how the tangent space is defined in most
> elementary textbooks on _algebraic_ geometry.

Ah, thanks for the information. I have never read a single line,
let alone a /book/ about algebraic geometry :-)