Suppose I want to write a function that is given a pathname and
returns a new pathname with an "html" type. Presumably the caller of
this function is going to use this new pathname to read or write an
html file that is related to the file named by the original pathname.
It seems that the most portable (between OS's and Lisp
implementations) way to write this is this:
(defun html-pathname (original)
(make-pathname :type "html" :version :newest :defaults original))
I assume I need to specify the :version :newest if I want this code to
work correctly on a Lisp running on a versioned file system because
otherwise my html pathname will inherit whatever version the original
happened to be which may not be right--if the original is a "txt" file
that has been edited a lot it's version may be way higher than the
newest version of the corresponding html file. Is that right?
-Peter
P.S. Assuming I've actually analyzed this right, how many folks
actually bother to write code this way in order to be ready when
versioned file systems make a comeback?
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
I sure do. Actually, I should be more consistent with the :version bit,
but that's just that.
Cheers
Marco
Peter Seibel wrote:
> Suppose I want to write a function that is given a pathname and
> returns a new pathname with an "html" type. Presumably the caller of
> this function is going to use this new pathname to read or write an
> html file that is related to the file named by the original pathname.
> It seems that the most portable (between OS's and Lisp
> implementations) way to write this is this:
>
> (defun html-pathname (original)
> (make-pathname :type "html" :version :newest :defaults original))
>
> I assume I need to specify the :version :newest if I want this code to
> work correctly on a Lisp running on a versioned file system because
> otherwise my html pathname will inherit whatever version the original
> happened to be which may not be right--if the original is a "txt" file
> that has been edited a lot it's version may be way higher than the
> newest version of the corresponding html file. Is that right?
>
> -Peter
>
> P.S. Assuming I've actually analyzed this right, how many folks
> actually bother to write code this way in order to be ready when
> versioned file systems make a comeback?
>
+ Peter Seibel <·····@javamonkey.com>:
| Suppose I want to write a function that is given a pathname and
| returns a new pathname with an "html" type. Presumably the caller of
| this function is going to use this new pathname to read or write an
| html file that is related to the file named by the original pathname.
| It seems that the most portable (between OS's and Lisp
| implementations) way to write this is this:
|
| (defun html-pathname (original)
| (make-pathname :type "html" :version :newest :defaults original))
(defun html-pathname (original)
(make-pathname :type "HTML" :case :common
:version :newest :defaults original))
if I have understood earlier advice from Kent Pitman correctly.
(And it seems reasonable to me.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Peter Seibel <·····@javamonkey.com>:
>
> | Suppose I want to write a function that is given a pathname and
> | returns a new pathname with an "html" type. Presumably the caller of
> | this function is going to use this new pathname to read or write an
> | html file that is related to the file named by the original pathname.
> | It seems that the most portable (between OS's and Lisp
> | implementations) way to write this is this:
> |
> | (defun html-pathname (original)
> | (make-pathname :type "html" :version :newest :defaults original))
>
> (defun html-pathname (original)
> (make-pathname :type "HTML" :case :common
> :version :newest :defaults original))
>
> if I have understood earlier advice from Kent Pitman correctly.
> (And it seems reasonable to me.)
It's probably an incremental improvement. But...
... it still cannot possibly work on MS-DOS (or similar 8.3
filesystems);
... it assumes, in some sense, that the filesystem name of a file is
made up of <name> + separator + <type>, or else that the Lisp
system or filesystem recognizes "html" as a semantic type.
Of course, I don't have any solutions to offer to this other than
"give up and go home".
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
> > + Peter Seibel <·····@javamonkey.com>:
> >
> > | Suppose I want to write a function that is given a pathname and
> > | returns a new pathname with an "html" type. Presumably the caller of
> > | this function is going to use this new pathname to read or write an
> > | html file that is related to the file named by the original pathname.
> > | It seems that the most portable (between OS's and Lisp
> > | implementations) way to write this is this:
> > |
> > | (defun html-pathname (original)
> > | (make-pathname :type "html" :version :newest :defaults original))
> >
> > (defun html-pathname (original)
> > (make-pathname :type "HTML" :case :common
> > :version :newest :defaults original))
> >
> > if I have understood earlier advice from Kent Pitman correctly.
> > (And it seems reasonable to me.)
>
> It's probably an incremental improvement. But...
>
> ... it still cannot possibly work on MS-DOS (or similar 8.3
> filesystems);
>
> ... it assumes, in some sense, that the filesystem name of a file is
> made up of <name> + separator + <type>, or else that the Lisp
> system or filesystem recognizes "html" as a semantic type.
Couldn't an implementor on MS-DOS combine those two ideas and
implement pathnames so that types are not not treated directly as file
extensions but rather as semantic types that are then mapped to
three-letter extensions in some implementation-defined (and probably
customizable) way. That is you might get this:
(file-namestring (make-pathname :name "foo" :type "html")) ==> "FOO.HTM"
Which is arguably The Right Thing given DOS's limitations.
-Peter
P.S. Not that this matters to the logical validity of your point, but
are there any CL implementations that run on DOS?
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> P.S. Not that this matters to the logical validity of your point, but
> are there any CL implementations that run on DOS?
Try:
http://www.webweasel.com/lisp/download.htm and
http://www.cs.biu.ac.il/~schwart/AIcourse.html (towards the bottom of the
page)
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Peter Seibel <·····@javamonkey.com>:
>
> | Suppose I want to write a function that is given a pathname and
> | returns a new pathname with an "html" type. Presumably the caller of
> | this function is going to use this new pathname to read or write an
> | html file that is related to the file named by the original pathname.
> | It seems that the most portable (between OS's and Lisp
> | implementations) way to write this is this:
> |
> | (defun html-pathname (original)
> | (make-pathname :type "html" :version :newest :defaults original))
>
> (defun html-pathname (original)
> (make-pathname :type "HTML" :case :common
> :version :newest :defaults original))
>
> if I have understood earlier advice from Kent Pitman correctly.
> (And it seems reasonable to me.)
Yes. I have seen Kent's discussiong of that point as well.
Unfortunately, in practice, in at least one implementation, that gets
you this on Unix:
CL-USER> (make-pathname :type "HTML"
:case :common
:version :newest
:defaults (pathname "/foo/bar/baz.txt"))
#p"/foo/bar/baz.HTML"
So practically speaking :case :common makes it less portable. You
could argue that that implementation is non-conformant. But you'd
have--I believe--a hard time making a rock solid case given that the
behvavior of case common depends on deciding what "customary case" is
on a given OS or filesystem which is up to the implementation. Given
that ambiguity and the existance proof that not all implementors sees
it the way Kent does, I'm leary of depending on :case :common.
Obviously if one wanted to make something really portable you could
use #+/#- to work around this implementation choice/lack of
conformance but I'm trying to avoid that at the moment and get a 90%
solution. (This is for my book and I haven't introduced readtime
conditionalization yet.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
+ Peter Seibel <·····@javamonkey.com>:
| Unfortunately, in practice, in at least one implementation, that gets
| you this on Unix:
|
| CL-USER> (make-pathname :type "HTML"
| :case :common
| :version :newest
| :defaults (pathname "/foo/bar/baz.txt"))
| #p"/foo/bar/baz.HTML"
Ouch. What implementation is that?
| So practically speaking :case :common makes it less portable. You
| could argue that that implementation is non-conformant. But you'd
| have--I believe--a hard time making a rock solid case given that the
| behvavior of case common depends on deciding what "customary case" is
| on a given OS or filesystem which is up to the implementation.
Well, I can't imagine anybody successfully arguing that uppercase is
the "customary" case on Unix. So they would have to argue, instead,
that there /is/ no customary case for filenames on Unix, in which case
this behavior seems reasonable. Perhaps on MacOS X you can argue
that. But then the standard filesystem on MacOS X is case
insensitive, so in some sense the result doesn't matter much. I am
less sure how you would argue this on other unixes.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Peter Seibel <·····@javamonkey.com>:
>
> | Unfortunately, in practice, in at least one implementation, that gets
> | you this on Unix:
> |
> | CL-USER> (make-pathname :type "HTML"
> | :case :common
> | :version :newest
> | :defaults (pathname "/foo/bar/baz.txt"))
> | #p"/foo/bar/baz.HTML"
>
> Ouch. What implementation is that?
Allegro 6.2
> | So practically speaking :case :common makes it less portable. You
> | could argue that that implementation is non-conformant. But you'd
> | have--I believe--a hard time making a rock solid case given that the
> | behvavior of case common depends on deciding what "customary case" is
> | on a given OS or filesystem which is up to the implementation.
>
> Well, I can't imagine anybody successfully arguing that uppercase is
> the "customary" case on Unix. So they would have to argue, instead,
> that there /is/ no customary case for filenames on Unix, in which
> case this behavior seems reasonable. Perhaps on MacOS X you can
> argue that. But then the standard filesystem on MacOS X is case
> insensitive, so in some sense the result doesn't matter much. I am
> less sure how you would argue this on other unixes.
I believe the Allegro guys would argue, as you guessed, that there is
*no* customary case on Unix. That said, I think they're looking into
changing this in 7.0.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Joe Marshall
Subject: Re: Most portable way to make pathname?
Date:
Message-ID: <ad30veht.fsf@ccs.neu.edu>
Peter Seibel <·····@javamonkey.com> writes:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
>> + Peter Seibel <·····@javamonkey.com>:
>>
>> | Unfortunately, in practice, in at least one implementation, that gets
>> | you this on Unix:
>> |
>> | CL-USER> (make-pathname :type "HTML"
>> | :case :common
>> | :version :newest
>> | :defaults (pathname "/foo/bar/baz.txt"))
>> | #p"/foo/bar/baz.HTML"
>>
>> Ouch. What implementation is that?
>
> Allegro 6.2
The Franz guys seem to be having difficulty understanding character
case.
> I believe the Allegro guys would argue, as you guessed, that there is
> *no* customary case on Unix. That said, I think they're looking into
> changing this in 7.0.
They should look at their own Unix systems. I bet that there is
empirical evidence for a preferred case and I bet that it is what
everyone expects.
Joe Marshall <···@ccs.neu.edu> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > I believe the Allegro guys would argue, as you guessed, that there is
> > *no* customary case on Unix. That said, I think they're looking into
> > changing this in 7.0.
>
> They should look at their own Unix systems. I bet that there is
> empirical evidence for a preferred case and I bet that it is what
> everyone expects.
What evidence would that be? I see no evidence for any preference for
case on UNIX (of any flavor). It seems to be case indifferent. I see
people with a preference for case. I see filenames like these:
readme, Readme, ReadMe, and README. What I see more of depends on who
the author is.
In any case, ACl 7.0 implements pathname case. A beta is due out
soon.
From: Joe Marshall
Subject: Re: Most portable way to make pathname?
Date:
Message-ID: <vflosa4p.fsf@ccs.neu.edu>
Kevin Layer <·····@*n*o*s*p*a*m*franz.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> Peter Seibel <·····@javamonkey.com> writes:
>>
>> > I believe the Allegro guys would argue, as you guessed, that there is
>> > *no* customary case on Unix. That said, I think they're looking into
>> > changing this in 7.0.
>>
>> They should look at their own Unix systems. I bet that there is
>> empirical evidence for a preferred case and I bet that it is what
>> everyone expects.
>
> What evidence would that be? I see no evidence for any preference for
> case on UNIX (of any flavor). It seems to be case indifferent. I see
> people with a preference for case. I see filenames like these:
> readme, Readme, ReadMe, and README. What I see more of depends on who
> the author is.
Would you care to count the occurrances in these classes?
all-lower-case letters
all-upper-case-letters
capitalized (first character upper, rest lower)
mixed-case
<···@ccs.neu.edu> wrote:
>Would you care to count the occurrances in these classes?
>
>all-lower-case letters
>all-upper-case-letters
>capitalized (first character upper, rest lower)
>mixed-case
Here's one datapoint (my workstation):
lower: 515116
MiXeD: 85259
Ucfirst: 37848
UPPER: 21720
other: 4911
Total: 664854
The statistics are only for the inode name, not the whole path. Also,
since Unix doesn't have any concept of filetypes files like
"README.txt" are considered to be mixed case. Counting just everything
before the first dot as the filename wouldn't really change those
statistics all that much.
--
Juho Snellman
From: Joe Marshall
Subject: Re: Most portable way to make pathname?
Date:
Message-ID: <ad30bck0.fsf@ccs.neu.edu>
······@iki.fi (Juho Snellman) writes:
> <···@ccs.neu.edu> wrote:
>>Would you care to count the occurrances in these classes?
>>
>>all-lower-case letters
>>all-upper-case-letters
>>capitalized (first character upper, rest lower)
>>mixed-case
>
> Here's one datapoint (my workstation):
>
> lower: 515116
> MiXeD: 85259
> Ucfirst: 37848
> UPPER: 21720
> other: 4911
> Total: 664854
(/ 515116.0 664854.0) 0.77
over three quarters of the files are lower cased, and
(/ 515116.0 85259.0) 6.04
lower case exceeds the next-most-favored
option by more than a 6 to 1 ratio.
It sure looks like lower-case is the `preferred' case.
Joe Marshall <···@ccs.neu.edu> writes:
> It sure looks like lower-case is the `preferred' case.
I think you are confusing `preferred' and `predominate'. That is,
lower case files are in greater number, but they are no more desirable
than any other combination--at least in any UNIX I know of.
From: Joe Marshall
Subject: Re: Most portable way to make pathname?
Date:
Message-ID: <3c8r9je4.fsf@ccs.neu.edu>
Kevin Layer <·····@*n*o*s*p*a*m*franz.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> It sure looks like lower-case is the `preferred' case.
>
> I think you are confusing `preferred' and `predominate'. That is,
> lower case files are in greater number, but they are no more desirable
> than any other combination--at least in any UNIX I know of.
That opens up the question of who is doing the preferring and/or
desiring. Even in MS-DOS I might *prefer* lower case arbitrary length
pathnames and just be out of luck. But I think you can attribute the
predominance of lower case to a certain amount of preference (given
that Unix doesn't care).
+ Joe Marshall <···@ccs.neu.edu>:
| Kevin Layer <·····@*n*o*s*p*a*m*franz.com> writes:
|
| > Joe Marshall <···@ccs.neu.edu> writes:
| >
| >> It sure looks like lower-case is the `preferred' case.
| >
| > I think you are confusing `preferred' and `predominate'. That is,
| > lower case files are in greater number, but they are no more desirable
| > than any other combination--at least in any UNIX I know of.
|
| That opens up the question of who is doing the preferring and/or
| desiring.
Well, I have a hard time imagining an operating system which at the
same time allows both upper and lower case in filenames, yet makes one
kind more difficult to deal with than the other. But wait - there was
Eunice, a Unix emulator running under VMS, which I think had a
distinct lowercase preference, in that all lowercase filenames were
mapped to the corresponding all uppercase filenames that VMS could
handle, whereas upper og mixed case filenames were handled via various
kludges. I don't know if this is the sort of things the designers
thought of when they talked about preferred case in CL. I have always
assumed it referred to the case typically preferred by the typical
user of those systems: A people centric, not system centric point of
view. But I could be wrong, of course. And in any case, if anything,
I would guess the preference for all lowercase filenames is becoming
less prevalent, not more so, among unix users. At least if you count
the MacOS X crowd.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
From: Joe Marshall
Subject: Re: Most portable way to make pathname?
Date:
Message-ID: <65dm6bs7.fsf@comcast.net>
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> Well, I have a hard time imagining an operating system which at the
> same time allows both upper and lower case in filenames, yet makes one
> kind more difficult to deal with than the other.
Tops-20
--
~jrm
+ Joe Marshall <·············@comcast.net>:
| Harald Hanche-Olsen <······@math.ntnu.no> writes:
|
| > Well, I have a hard time imagining an operating system which at the
| > same time allows both upper and lower case in filenames, yet makes one
| > kind more difficult to deal with than the other.
|
| Tops-20
Hm. I'll have to take your word for it. My exposure to tops-20 has
been very limited.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Joe Marshall <·············@comcast.net>:
>
> | Harald Hanche-Olsen <······@math.ntnu.no> writes:
> |
> | > Well, I have a hard time imagining an operating system which at the
> | > same time allows both upper and lower case in filenames, yet makes one
> | > kind more difficult to deal with than the other.
> |
> | Tops-20
>
> Hm. I'll have to take your word for it. My exposure to tops-20 has
> been very limited.
Kent Pitman explained it quite well in this post:
<http://groups.google.com/groups?selm=sfwogwkbmbw.fsf%40world.std.com>
Short version, as I understand it, is on Tops-20, the only way to
include lowercase letters in a filename was to escape them. Thus if
you created a file named "foo", the user could only refer to it
outside of Lisp as "^Vf^Vo^Vo" where "^V" was the escape character to
preserve case; otherwise "foo" would get automaticalyl converted to
"FOO" (much like the Lisp reader treats symbols.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
By the way, I put forth that Windows has no preferred case either. In
cmd.exe (on NT), if you do "copy con foo" and type ^Z, you'll get a
file named `foo' not `Foo' or `FOO'. If you do "copy con BAR" you'll
get a file named `BAR'. I've never see a Windows program change the
case of something I typed.
"Kevin Layer" <·····@*n*o*s*p*a*m*franz.com> wrote in message
···················@*n*o*s*p*a*m*franz.com...
> By the way, I put forth that Windows has no preferred case either. In
> cmd.exe (on NT), if you do "copy con foo" and type ^Z, you'll get a
> file named `foo' not `Foo' or `FOO'. If you do "copy con BAR" you'll
> get a file named `BAR'. I've never see a Windows program change the
> case of something I typed.
>
It's just syntactic sugar. In Windows, Foo == FOO == fOo == ...
From: james anderson
Subject: Re: Most portable way to make pathname?
Date:
Message-ID: <40412154.B87B0B1E@setf.de>
Peter Seibel wrote:
>
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
> > + Peter Seibel <·····@javamonkey.com>:
> >
> > | Suppose I want to write a function that is given a pathname and
> > | returns a new pathname with an "html" type. Presumably the caller of
> > | this function is going to use this new pathname to read or write an
> > | html file that is related to the file named by the original pathname.
> > | It seems that the most portable (between OS's and Lisp
> > | implementations) way to write this is this:
> > |
> > | (defun html-pathname (original)
> > | (make-pathname :type "html" :version :newest :defaults original))
> >
> > (defun html-pathname (original)
> > (make-pathname :type "HTML" :case :common
> > :version :newest :defaults original))
> >
> > if I have understood earlier advice from Kent Pitman correctly.
> > (And it seems reasonable to me.)
>
> [an issue with :case :common which happens to involve html]
>
> Obviously if one wanted to make something really portable you could
> use #+/#- to work around this implementation choice/lack of
> conformance but I'm trying to avoid that at the moment and get a 90%
> solution. (This is for my book and I haven't introduced readtime
> conditionalization yet.)
it is difficult to get something like .htm / .html right without admitting
conditionalization. if one is willing to use logical pathnames, they could
well work to ones advantage in this particular situation, in that the logical
pathname type would be fixed, but one would have to conditionalize the type of
the to-wildname.
...