ACL, CLISP and pathnames
Erik Naggum
* Sam Steingold
| So, ACL cannot read what CLISP writes readably.
like that's a bombshell.
| Whose bug is this - ACL's or CLISP's?
why is that even a question? CLISP has a _really_ bad rap sheet when it
comes to conformance, and there's _nothing_ to support its behavior in
this case, either. neither the #S(PATHNAME ...) hack nor the stupid
#"..." form is anywhere _near_ standard. (this is not to imply that
Allegro CL is always a priori conforming, but when you have a case of
total lack of support for the opponent, why look further?)
| CLHS doesn't seem to specify #S syntax for pathnames, only #p, so,
| apparently, ACL is standard-compliant here. Or am I missing something?
no, Allegro CL is conforming.
| Is there a simple workaround?
yes, write your own print method for pathnames in CLISP.
| Can I advise ACL to call `make-pathname' when seeing #S(PATHNAME)?
not that I know of.
#:Erik
--
Support organized crime: use Microsoft products!
Erik Naggum
* Sam Steingold
| E.g., CLISP has :key in reduce and ACL doesn't (I do have the fix,
| thanks).
criminy! are you still carping on that? it's been fixed! how many
times do I have to _tell_ you this? if you were a paying customer, you
would get the patch that implements :KEY to REDUCE. Franz Inc responded
to my actual need for it _promptly_. the patch is available for all
supported platforms for Allegro CL version 4.3.1:
patch0306-01.fasl : Implements the :key argument to reduce
since you're using the _expressly_unsupported_ Allegro CL version 4.3 for
Linux, _why_ do you keep _lying_ about the standard, supported version?
and _how_long_ are you going to keep lying about it? if you _want_ the
patch for the Linux version, pay for the support and you'll get it.
| BTW, you don't have to be so abusive. Relax.
there's something you can do, too, you know. you can stop lying about
problems that have been solved, for one thing.
| What other conformance issues do you want to be addressed?
all of them. e.g., I _need_ the UPDATE-INSTANCE-FOR-REDEFINED-CLASS
protocol in my CLOS applications, to take one _serious_ issue.
| Are you suggesting that I do
|
| (defmethod print-object ((path pathname) stream)
| (format stream "#p\"~a\"" path)) ; doesn't work
|
| or something like this?
yes, but there's a little more to implementing PRINT-OBJECT method than
that, like obeying a lot of printer control variables. I have written a
new PRINT-OBJECT on SYMBOL to make Allegro CL work right while waiting
for the real fix in ACL 5.0 (see? I can wait for fixes, too, but I do
something about the problems in the meantime, I don't complain for months
on end to newsgroups and public fora), and it was lot of work, but it
_is_ eminintly possible to fix such things. you figure out what you need
in CLISP, though, since you want to use CLISP. I sure don't.
Erik Naggum
* Sam Steingold
| if you were a paying customer of CLISP ... :-)
get real.
| I said: ACL 4.3 for linux doesn't have :key in reduce. Do you dispute this?
| (the wording was different, but the meaning was unambiguous).
well, you failed to get your intended unambiguity across, and I'm tired
of that complaint from you regardless of your intent. if I could see
what would satisfy you, things would be a little different, but I can't.
| Please stop your abuse.
do you really think I beat you over the head _unprovoked_? geez!
| BTW, CLISP is GPLed, so, if you unhappy with it, you are welcome to join
| the development. (leaving the abuse and insults outside, of course).
I have been informed that the CLISP sources are now to be distributed and
worked on in the language C, as opposed to the language D, which differs
only from C in that comments have a gratuitiously different syntax, as
far as I could tell. such gratuitous braindamage is not conducive to
cooperation. I have also said previously that to get people to work on
some source code, you have to adhere to some reasonable coding standards.
CLISP is the _ugliest_ code I have ever seen, possibly excluding Kyoto
Common Lisp and the MULE code in GNU Emacs. neither of these invite
people to fix them. the cognitive load is too high, and just cleaning it
all up is a gargantuan effort.
| Why do you think your abuse and insults of CLISP to be legitimate while
| denying me a right to comment on ACL?
that question is valid only if you ignore the fact that you have a very
different idea about what constitues "unambiguous" in your incessant
complaints than I do. the fact that you got a simple fix from me, and a
suggestion to write your own REDUCE if you really had to have this, yet
_continue_ to complain, but "invite" me to fix CLISP when you can't be
bothered to fix things for yourself, suggests that you suffer from a
one-sided view of the situation. I object vociferously to your leniency
towards an anti-conforming free software product and your incessant
whining about a commercially supported and highly superior product in all
respects. in brief, I'm trying to establish the balance that you have
perturbed. you beat up ACL and extol CLISP. I do the reverse. it sort
of evens out, except that ACL _is_ of high quality, and CLISP will be of
high quality sometime in the distant future, good men and gods willing.
Barry Margolin
May I make a comment as a disinterested, (hopefully) unbiased, third party?
In article <31040702...@naggum.no>, Erik Naggum <c...@naggum.no> wrote:
>* Sam Steingold
>| if you were a paying customer of CLISP ... :-)
>
> get real.
>
>| I said: ACL 4.3 for linux doesn't have :key in reduce. Do you dispute this?
>| (the wording was different, but the meaning was unambiguous).
>
> well, you failed to get your intended unambiguity across, and I'm tired
> of that complaint from you regardless of your intent. if I could see
> what would satisfy you, things would be a little different, but I can't.
Sam's post that mentioned :KEY also said that he was aware of the fix. He
was simply pointing out one place where he knew of a feature that the base
ACL was missing but CLISP wasn't.
>| Please stop your abuse.
>
> do you really think I beat you over the head _unprovoked_? geez!
Sam's original post asked a very simple question in a very civil manner;
his later post simply made an observation, not a complaint. Your responses
had a very confrontational tone. I can't see how anything in Sam's posts
in this thread could have provoked your attitude.
Is there some other context that you're referring to when you say he
provoked you?
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Rainer Joswig
In article <02p61.43$EA.11...@cam-news-reader1.bbnplanet.com>, Barry
Margolin <bar...@bbnplanet.com> wrote:
> May I make a comment as a disinterested, (hopefully) unbiased, third party?
>
> In article <31040702...@naggum.no>, Erik Naggum <c...@naggum.no> wrote:
> >* Sam Steingold
> >| if you were a paying customer of CLISP ... :-)
> >
> > get real.
> >
> >| I said: ACL 4.3 for linux doesn't have :key in reduce. Do you dispute this?
> >| (the wording was different, but the meaning was unambiguous).
> >
> > well, you failed to get your intended unambiguity across, and I'm tired
> > of that complaint from you regardless of your intent. if I could see
> > what would satisfy you, things would be a little different, but I can't.
>
> Sam's post that mentioned :KEY also said that he was aware of the fix. He
> was simply pointing out one place where he knew of a feature that the base
> ACL was missing but CLISP wasn't.
>
> >| Please stop your abuse.
> >
> > do you really think I beat you over the head _unprovoked_? geez!
>
> Sam's original post asked a very simple question in a very civil manner;
> his later post simply made an observation, not a complaint. Your responses
> had a very confrontational tone. I can't see how anything in Sam's posts
> in this thread could have provoked your attitude.
Yep!
--
http://www.lavielle.com/~joswig/
Erik Naggum
* Barry Margolin
| May I make a comment as a disinterested, (hopefully) unbiased, third party?
sure. sorry for the response time, though, a new project is coming up.
| Sam's post that mentioned :KEY also said that he was aware of the fix.
uhm, he was aware of the patch to ACL 4.3 that I had sent him, but it did
not look to me like he believed that it had been fixed _officially_ in or
for a later release, a fact of which I have informed him several times,
despite which he keeps carping on this problem. granted, I can be nasty
about bugs in software, too, but at least I _stop_ when they get fixed.
| He was simply pointing out one place where he knew of a feature that the
| base ACL was missing but CLISP wasn't.
what's a "base ACL"? see, this is where the ambiguitiy comes in. Sam
thought he was unambiguous in talking about the ACL 4.3 for Linux
offering, but the statement was general and referred to the whole product
without qualification. however, whether a product for which there has
been published a patch to a reported problem can be said to exist without
the patch is a question of some relevance, but my take on it is that if a
patch has been issued _and_ you have a problem that the patch fixes, then
you have only one thing to do: install the patch.
| Sam's original post asked a very simple question in a very civil manner;
| his later post simply made an observation, not a complaint. Your
| responses had a very confrontational tone. I can't see how anything in
| Sam's posts in this thread could have provoked your attitude.
I think I already explained this adequately, but to recap: Sam seems very
lenient with the bugs and non-conformance issues in CLISP, to the point
where he even suggests that _I_ join the team and help fix things, while
he's incredibly upset with this REDUCE/:KEY problem and _any_ problem he
finds in Allegro CL, always taking CLISP's side, as it were, deservedly
or not. e.g., he only very reluctantly accepted the patch I offered him
(_twice_, before he accepted it), and then had the gall to complain that
it was slow, but without any sign of effort on his part to fix his own
problems. again, I can be harsh on bugs in Allegro CL myself, but
towards Franz Inc, not the newsgroups, and I usually make a big effort to
either debug, help solve, or circumvent the problem through advice to the
offending functions.
and I don't think civil manners is a virtue when what you're doing is
destructive. it reminds of the _least_ admirable side of politicians who
are trying to get people to vote for them based on charisme, not on what
they do or their real intentions.
| Is there some other context that you're referring to when you say he
| provoked you?
well, yes, the whole history of the REDUCE/:KEY bug and Sam's history of
being decidedly lop-sided in favor of CLISP and against Allegro CL, the
total lack of predictability as to when he'll quit repeating complaints
about bugs that have been fixed, and
Steve Gonedes
Sam Steingold <s...@usa.net> writes:
< Internet socket interface (ACL might have this too, I just could not
< find it so far. If it does, please tell me about it).
It's a shared library and a fasl. It's usable like with-open-file; the
socket is just another stream.
There's also a regexp thing there too, sometimes it's pretty usefull.
I agree with you that it would be nice if there was source code; but
there isn't.
Erik Naggum
* Sam Steingold
| First of all, I would like to thank Barry and Rainer for defending me.
they weren't. Barry was critical of the force of my reactions, and
Rainer agreed. I have a very hard time reading them as defending you or
lending your moral support for the kind of followup you produced to my
response to Barry.
interpreting Barry's article as defense for your behavior is just as
unwarranted as every other unwarranted assumption you make and for which
I have criticize you. if I had stood up to make the kind of response he
did, I sure as hell would be deeply _embarrassed_ if the person I had
implicitly "defended" had come back to make all the vile personal and
completely _irrelevant_ insults that you suddenly feel free to make, now.
at least I "insult" you for what you _do_ that has relevance to this
newsgroup, not for something you supposedly _are_. however, the latter
is unavoidable, now. you _are_ a bad person, Sam Steingold.
you had beeter learn that just because you have been "defended" doesn't
mean you are right or that you can start to attack people. if you think
people "defend" _you_ and will remain on your side if you abuse their
"defense", you are gravely mistaken about the nature of their gesture.
if anything in a tenous situation, you should at the very least make an
effort to be smart enough not to cause people to dislike _you_ instead of
just some of the things you do. gloating and grinning and strutting like
you do here is evidence of somebody who knows he's been under _rightful_
attack and thinks he can get away with it. it's sickening to watch.
| In addition to the emotional support, their defense brought Erik to state
| his accusations without his usual insults (almost), so I can answer them.
you really are a piece of garbage, Sam. I am civil to Barry because
Barry is not the stinking moron that you prove yourself to be in the
message I respond to now. in fact, I have great respect for Barry and
his work, and none at all for you or yours. you appear to think the
civility of my response to Barry had some other cause than the fact that
Barry has not in any possible way offended me. I wonder what kind of
sick mind you have that fails to realize at this point that I don't like
what you do because of something you actually _do_.
what I see from you now is the stupid kid who some smart, caring adult
thinks should be given a break, only to observe that the stupid kid goes
on the rampage with insults and worse back because he thinks the caring
adult won't leave him to himself and get what he deserves. the stupid
kid thus shows an utter lack of understanding of any of the dynamics
involved, and instead hurls forth such stupid lines as these:
| Erik, you are always interpreting everything in a detrimental manner.
| Not every statement qualifies as a complaint, unless, of course, you are
| looking for an opportunity to insult me.
| I wonder what else you were about to invent about me.
| It is sad that I have to post this (obviously `noise'-type) article.
| Unfortunately, there is little hope that Erik will ever learn to be civil
| Why don't we create a special newsgroup
| comp.lang.lisp.moral-support-for-victims-of-naggum's-abuse? :-)
I have a _real_ low tolerance for idiots everywhere, as determined by
their behavior in context I have to deal with it, which is _all_ I care
about.. while I try to give some fairly strong hints that I dislike
somebody's behavior as long as I care enough about their input and what
they might do _other_ than being despicable morons and this sometimes
looks ugly to some sensitive people, I feel nothing towards the _person_
in question. if I do, I have to get rid of the person from my context,
which on USENET is fortunately possible with kill and score files. the
key to understand this difference is that if and when they change their
behavior, my criticism ceases, indeed I never criticize unless the
specifically annoying behavior is present. if I were to dislike the
_person_, that _wouldn't_ go away. however, it has become clear to me
that Samuel Steingold is not the kind of person who should be given any
benefit of doubt at all, anymore. his rejoinder to my response to Barry
is sufficient evidence of a despicably bad _person_. his insanely broad
generalizations about areas he knows nothing about proves that he is not
of the kind who knows the difference between his own projections and
facts, which simply means that he is producing _only_ noise, and it was
the incessant noise that I tried to stop or at least limit. I have
failed in that regard, of course, seeing that some of the really bad
morons out there aren't able to introspect sufficiently to realize that
_maybe_ what they observe has _something_ to do with their own behavior.
I can only hope that Barry and Rainer find that it is worth their while
to teach the stupid kid they care about why he was being treated harshly
and how he can do something about it himself.
guesswork, randomly disconnected assumptions and wild generalizations
have been the underlying problem in my dealing with Samuel Steingold for
a very long time. I have helped this stinking moron with Lisp problems,
with Allegro-specific problems, with Emacs problems, and all I get back
is "you are ALWAYS interpreting EVERYTHING in a detrimental manner".
gee, thank you. I have responded to many of his questions without any
trace of hostility, instead with helpfulness, concern and a desire to
make what he fails to be able to make work, work for him, and I daresay I
know how to be civil and were in the beginning, yet what I get back is
"there is little hope that Erik will ever learn to be civil".
creep like Samuel Steingold deserve to be ostracized from the Net, not
for their moronic attitude problems, but for how they deal with people
who stand up for them.
Barry, Rainer, I hope you take it upon yourself to explain to this creep
what exactly you critized in my reactions towards him and what you do and
do not "defend". I have reason to believe that you are sufficiently
upright people to make it plain and clear to this creep that you do not
in fact condone or defend the behavior he shows in the article I respond
to now. please do it by mail, as he has proven to be the kind of person
who believes a public form warrants somewhat less than decent behavior
and responses as soon as he thinks he has an advantage over somebody.
exit Sam Steingold.
Rainer Joswig
Erik Naggum wrote in message <31043985...@naggum.no>...
> Barry, Rainer, I hope you take it upon yourself to explain to this creep
> what exactly you critized in my reactions towards him and what you do and
> do not "defend".
I'm very grateful to all the people who have provided contributions
to the benefit of the Lisp community.
A discussion *style* like this doesn't do much good, though.
What was the original question? Yes, ACL is much more advanced than
CLISP. It does adhere to the standards much more than CLISP. Franz
did a ***great*** job providing the excellent ACL 4.3 for Linux. I hope they
are going to port ACL 5.0 to Linux.
CLISP may have *some* weak points. Still I found it to be extremely useful.
Things like printing of pathnames should be fixable by the maintainers of
CLISP.
I guess some free implementations may do this already correctly.
Some code sharing may be possible. Helping to improve CLISP should
be an important goal. For those who are interested: more information about
CLISP can
be found on http://www.cons.org/~haible/packages-clisp.html . There
is a mailing list for CLISP users and one for the maintainers.
Erik Naggum
* Rainer Joswig
| A discussion *style* like this doesn't do much good, though.
well, there are good and there are bad ways to respond when people
"defend" you. I find it puzzling that you appear to like _his_ style.
| Franz did a ***great*** job providing the excellent ACL 4.3 for Linux. I
| hope they are going to port ACL 5.0 to Linux.
they already have. take a look in ftp.franz.com/pub/linux/acl50beta/.
both RedHat 4.X and RedHat 5.X are supported¹. I'm running both 4.3 and
5.0-beta on a RedHat 4.2 system right now. no negative surprises so far,
but several really positive ones, like the new printer and reader which
implements the ANSI Common Lisp semantics correctly, not just the Franz
Inc "case mode" semantics, on which I filed a non-conformance report over
a year ago and had to fix with my own PRINT-OBJECT method on SYMBOL², the
:LOCAL-HOST argument to MAKE-SOCKET that I had asked for so I could bind
a socket on a single network interface (although still undocumented), and
numerous other things I have wanted and asked for, not the least of which
is improved ANSI Common Lisp conformance in numerous minor ways.
the _only_ problem I have with the free Linux release is that the ability
to get full support and be allowed to use this software in a commercial
setting is buried under a tremendous amount of legalese that says
INTERDIT, VERBOTEN and PROHIBITED every which way, when all you need to
do is make a phone call or write some e-mail to initiate the process that
produces the required "prior written consent". I think it's wonderful
that Franz Inc ships this Linux beta release for free, but I do wonder
what the effect will be on those who see it as marketing with a STOP sign
backdrop. how many will read the license and understand that only if
they _don't_ ask for (or get) permission to do cool stuff will it apply
as is? maybe it's just me who is still not used to the contract culture
in the U.S., but it seems much less accessible than it actually is, and I
should know: a client of mine is moving their production environment to
Allegro CL for Linux this summer.
#:Erik
------
¹ officially only RedHat 4.0 and RedHat 5.0.
² src.naggum.no/lisp/symbol-printer.cl (http and ftp)
--
"Where do you want to go to jail today?"
-- U.S. Justice Department's Windows 98 slogan
Kent M Pitman
Erik Naggum <c...@naggum.no> writes:
> * Sam Steingold
> | So, ACL cannot read what CLISP writes readably.
> | Whose bug is this - ACL's or CLISP's?
>
> why is that even a question? CLISP has a _really_ bad rap sheet when it
> comes to conformance, and there's _nothing_ to support its behavior in
> this case, either. neither the #S(PATHNAME ...) hack nor the stupid
> #"..." form is anywhere _near_ standard. [...]
Rap sheets? Hmm.... Must be talking some seriously illegal syntax here. :-)
In the US, we generally don't admit your prior criminal record as
evidence in a criminal trial unless it has some special relevance to
the current case. Forgetting CLISP's alleged "bad rap sheet", I see
nothing wrong with the #S(PATHNAME ...) hack, which is not required
but also is not forbidden. The #P output, while it looks portable,
really isn't because the stuff between the strings is interpreted in
an implementation-defined way; technically
#P"(PATHNAME NAME FRED TYPE LSP)"
is legal if the implementation wants to define it. (Gotta be a little
careful with colons, but that's why I omitted them here.)
I have long advocated that #S notation would make a GOOD fallback for
arrays, hash-tables, and odd pathnames that will lose info if printed
normally and should be used when *PRINT-READABLY* is T. e.g.,
(MAKE-PATHNAME :name "foo" :type nil) => #P"foo"
(MAKE-PATHNAME :name "foo" :type :unspecific) => "#P"foo"
so how do you print this readably? I think you acknowledge that an
unfilled pathname has no equal as a host file syntax, and you
print the former as
#S(PATHNAME :NAME "FOO" :CASE :COMMON)
or something like that.
In most cases of discrepancies among pathnames, the answer is
"both are correct" in that the pathname system is vague exactly to
allow a lot of implementations to co-exist. Users need to define
where this vagueness gets in the way of portability of common needs
and ask for further clarification.
Howard R. Stearns
In addition to the fact that the interpretation of #P"xxx" can vary
between implementations (as Kent points out), it can also vary within
the same lisp image/session, depending on the how the current value of
*default-pathname-defaults* effects the parsing of namestrings. This is
why Eclipse also uses #S(PATHNAME ...) syntax when *print-readably* is
true.
In the case of Eclipse, the #s syntax follows the general #S structure
style -- only the "slots" of the pathname are output, not additional
arguments to MAKE-PATHNAME such as :CASE or :DEFAULT. (This means that
the values of components must be displayed in :LOCAL :CASE.)
Kent M Pitman
"Howard R. Stearns" <how...@elwood.com> writes:
> In addition to the fact that the interpretation of #P"xxx" can vary
> between implementations (as Kent points out), it can also vary within
> the same lisp image/session, depending on the how the current value of
> *default-pathname-defaults* effects the parsing of namestrings. This is
> why Eclipse also uses #S(PATHNAME ...) syntax when *print-readably* is
> true.
My point about #P was, though, not to emphasize that the print rep can vary,
but rather to point out that implementations can diverge because it's a
given that the interpretation of #P's string is implementation-dependent.
> In the case of Eclipse, the #s syntax follows the general #S structure
> style -- only the "slots" of the pathname are output, not additional
> arguments to MAKE-PATHNAME such as :CASE or :DEFAULT. (This means that
> the values of components must be displayed in :LOCAL :CASE.)
I think this is a mistake, since #S has half-a-hope of being portable
if :CASE :COMMON is shown and the case shown is translated to common case
(regardless of the intenral format). If :CASE :DEFAULT or :CASE :LOCAL
is used, the #S output can't possibly be portable. Of course, since #S
is usually not printable re-readably, this may not matter a lot.
Howard R. Stearns
Kent M Pitman wrote:
>
> "Howard R. Stearns" <how...@elwood.com> writes:
>
> > In addition to the fact that the interpretation of #P"xxx" can vary
> > between implementations (as Kent points out), it can also vary within
> > the same lisp image/session, depending on the how; the current value of
> > *default-pathname-defaults* effects the parsing of namestrings. This is
> > why Eclipse also uses #S(PATHNAME ...) syntax when *print-readably* is
> > true.
>
> My point about #P was, though, not to emphasize that the print rep can vary,
> but rather to point out that implementations can diverge because it's a
> given that the interpretation of #P's string is implementation-dependent.
>
> > In the case of Eclipse, the #s syntax follows the general #S structure
> > style -- only the "slots" of the pathname are output, not additional
> > arguments to MAKE-PATHNAME such as :CASE or :DEFAULT. (This means that
> > the values of components must be displayed in :LOCAL :CASE.)
>
> I think this is a mistake, since #S has half-a-hope of being portable
> if :CASE :COMMON is shown and the case shown is translated to common case
> (regardless of the intenral format).
Really? I am under the impression that the :local case must match the
usual conventions for the OS, while the :common case is completely
undefined. For example, I would guess that for all Unix Lisp
implementations:
(directory-namestring (make-pathname :directory "foo" :case :local))
=> "/foo/" ;(or perhaps "/foo"), but
(directory-namestring (make-pathname :directory "FOO" :case :common))
=> "/FOO/" or "/foo" or "/Foo" or ... ; similarly for ...:directory
"foo" ...
In other words, it seems to me that an expression like (make-pathname
.... :case :local) is more likely to be produce the pathnames with
identical namestrings on different implementations than an expression
like (make-pathname ... :case :common).
I hope that given how symbols and logical pathnames are defined, its not
unreasonable for an implementation to use capital letters as the :common
case stored in pathname structures, but I don't think there is any
reason to assume that this is what ALL implementations do. (I say
"hope" because that's what Eclipse does, see
http://www.elwood.com/eclipse/path.htm#case for the Eclipse definition
of :common case. And yes, I know the definition there means that
comparing pathnames on case-insensitive file systems is an issue, but it
would be anyway.)
It also seems to me that the text #s(pathname ... ) is more likely to be
be readable on different systems than text like #s(pathname ... :case
:common). (This was actually the original point behind my "following
the structure conventions" comment.) It is only an accident (or
inspiration on the part of Kent and his colleagues) that both these
assertions ("local case has more clearly defined semantics" and "case
might not be a slot, so don't use it in #s(pathname ...) syntax") can
work together -- the default for make-pathname is :local case, so we can
leave it off of the #s(pathname ...) syntax and assume local case, with
nicely defined semantics.
Perhaps its this last sentence that you are disagreeing with. For
example, perhaps you're saying that you could imagine an implementor
supporting #s(pathname ...) syntax by filling in the slots directly,
without changing case. Yes, this would break protability under my
assumptions. However, IMHO, such an implementation would violate the
spirit of #s(...) syntax, because make-pathname is defined to use :local
case by default. If an implemeentation fills in slot values directly
without calling make-pathname, and if the components it expects to find
stored in slots are assumed to be canonicalicalized in common case, then
they really should always supply :case :common in their #s(pathname ...
) syntax, and (ideally) should signal an error if they find :case :local
or no mention of case at all. Otherwise the behavior is different than
the ANSI spec for make-pathname.
(In other words, I'm assuming that #s(xxx ...) syntax, if supported at
all for xxx, behaves exactly as if make-xxx were actually called, rather
than blindly filling in slots.)
> If :CASE :DEFAULT or :CASE :LOCAL
> is used, the #S output can't possibly be portable. Of course, since #S
> is usually not printable re-readably, this may not matter a lot.
I'm not following this.
Kent M Pitman
"Howard R. Stearns" <how...@elwood.com> writes:
> Kent M Pitman wrote:
> >
> > "Howard R. Stearns" <how...@elwood.com> writes:
> >
> > > In addition to the fact that the interpretation of #P"xxx" can vary
> > > between implementations (as Kent points out), it can also vary within
> > > the same lisp image/session, depending on the how; the current value of
> > > *default-pathname-defaults* effects the parsing of namestrings. This is
> > > why Eclipse also uses #S(PATHNAME ...) syntax when *print-readably* is
> > > true.
> >
> > My point about #P was, though, not to emphasize that the print rep can vary,
> > but rather to point out that implementations can diverge because it's a
> > given that the interpretation of #P's string is implementation-dependent.
> >
> > > In the case of Eclipse, the #s syntax follows the general #S structure
> > > style -- only the "slots" of the pathname are output, not additional
> > > arguments to MAKE-PATHNAME such as :CASE or :DEFAULT. (This means that
> > > the values of components must be displayed in :LOCAL :CASE.)
> >
> > I think this is a mistake, since #S has half-a-hope of being portable
> > if :CASE :COMMON is shown and the case shown is translated to common case
> > (regardless of the intenral format).
>
> Really? I am under the impression that the :local case must match the
> usual conventions for the OS, while the :common case is completely
> undefined.
You have :local right but :common confused. It depends on whether you "intend"
a case (which most people do not, even though they don't know it) or whether
you "intend" usual-case-p.
If you are using an operating system in which there is the possibility of both
cases but in which uppercase is the natural case, such as TOPS-20, you
REALLLY REALLY REALLY REALLY do NOT want
(make-pathname :name "foo" :type :local)
because I'll argue that 90% of the users never even knew how to type the escape
character needed to let you use lowercase chars in the operating system.
You would therefore be making a REALLY hard to type filename. In TOPS-20,
all filenames are defaultly upcased (just like lisp symbols) UNLESS you put
a control-V in front of each filename char to retain preserved case (like
backslash in common lisp). There are other file systems which were like
this. I'm not sure what the deal is with VAX VMS, but I know it normally
translates filenames to uppercase and I don't know if it allows lowercase.
A file created as (make-pathname :directory '(:absolute "JDOE")
:type "LSP" :name "FOO" :case :common) will be CORRECTLY
created as <JDOE>FOO.LSP.0 on TOPS-20, as [JDOE]FOO.LSP;0 on
VAX VMS, as JDOE;FOO LSP on ITS, as >jdoe>foo.lsp on Multics,
as /jdoe/foo.lsp on Unix, as \jdoe\foo.lsp on DOS, as :jdoe:foo.lsp
on Mac. What is unpredictable about that? If you're targeting case
it's unpredictable but if you're targeting "naturalness" it's absolutely
predictable. On the other hand, the same call with :case :local will
be created as <^Vj^Vd^Vo^Ve>^Vf^Vo^Vo.^Vl^Vs^Vp (INCORRECT) on TOPS-20,
but JDOE;FOO LSP on ITS (where there is no lowercase). Predictable?
Yes, if you wanted to predict the case; no, if you wanted to predict
that a useful file got created.
The purpose of :case :common is also to let you do things like
(make-pathname :name "FOO" :type "tmp" :case :common)
so that it WILL predictably create a hard-to-type temp file name
if possible.
But even in the ordinary case of believing there are only three operating
systems in the world (PC, Mac, and Unix), you get predictability of
case and naturalness, it's just that naturalness is inverted from what
you expect for some historical reasons. There's nothing unpredictable
about how (pathname-name (make-pathname :case :common :name "FOO"))=>"foo"
in each of these systems. Nor is there anything unpredictable about
how (pathname-name (make-pathname :case :common :name "foo"))=>"FOO"
Was there really something unclear in the spec about this? Because I
don't think there was.
> For example, I would guess that for all Unix Lisp
> implementations:
> (directory-namestring (make-pathname :directory "foo" :case :local))
> => "/foo/" ;(or perhaps "/foo"), but
> (directory-namestring (make-pathname :directory "FOO" :case :common))
> => "/FOO/" or "/foo" or "/Foo" or ... ; similarly for ...:directory
> "foo" ...
No, both
(directory-namestring (make-pathname :directory "foo" :case :local))
and
(directory-namestring (make-pathname :directory "FOO" :case :common))
yield "/foo/" or "/foo" but not "/FOO" for Unix, Mac, and DOS.
There is nothing unpredictable about this.
> In other words, it seems to me that an expression like (make-pathname
> .... :case :local) is more likely to be produce the pathnames with
> identical namestrings on different implementations than an expression
> like (make-pathname ... :case :common).
Yes, :case :local is likely to produce strings of the same CASE.
But not of the same USEFULNESS. Some operating systems PREFER a different
case, and it's wrong when writing portable code to try to force a case
unless you want your app to be the only one in all the operating system
to produce the wrong case filenames. I promise you--your users will
report THAT as unpredictable in that on some operating systems your program
works normally but on others your programs screws up the output and puts
it in filenames no other program can find.
> I hope that given how symbols and logical pathnames are defined, its not
> unreasonable for an implementation to use capital letters as the :common
> case stored in pathname structures, but I don't think there is any
> reason to assume that this is what ALL implementations do.
That isn't the point. You might have to case-translate to do the output.
The question is what is MEANT by :LOCAL. :LOCAL says "It is more important
to me to have this case than to have the operating system natural case."
:COMMON says "It is more importnat to me to have the operating system
natural case than to force the case."
Since portability is always about doing what's natural on the target platform,
portability is sunk when you use :local. It will never be plug-compatible
with all possible targets except in the rare case that your program never
interacts with any other programs or users on the target platform and can
make whatever filenames it wants without anyone ever caring.
Howard R. Stearns
You are right, I was misinterpretting :case :common. (I was working
backwards from how I had internalized pathnames might be implemnented,
rather than just looking at the spec.) The spec IS fine, though I do
think that Steele's additional comments in CLtL2 are ALMOST necessary
for a full understanding.
So given all that, and also, for the record, understanding that no
implementation is required to either generate or read #s(pathname ...)
syntax, I'm still not clear on what we should all do if we wanted to
make readable pathnames most portable.
For example, suppose we do all decide to use #s(pathname ...) syntax.
Should the tokens :case :common explicitly appear in the syntax? One
could argue that MAKE-PATHNAME accepts the :case &key argument, so this
is fine. Nonetheless, it seems verbose and ungainly to have to always
put it there.
We could leave it off and declare that #s(pathname ...) lists the
components in :common :case, but I hate the idea of having #s(pathname
....) not work like #.(make-pathname ...).
Alternatively, we could allow it to be left off, and maintain that
reading #s(pathname ...) must be handled as though (make-pathname ...)
were called. (For this conversation, I'm ignoring the package issues
with the #s reader.) If no :case :common appears, then, as is always the
case with make-pathname, :case :local is assumed.
Now, just to be clear, if someone uses #s(pathname ...) notation under
this scheme, and does't put :case :common, then they had better report
the components using the local conventions. For example:
unix: #P"/usr/foo/bar.lisp" =>
#s(pathname :host xxx :directory '(:absolute "usr" "foo")
:name "bar" :type "lisp")
windows: #P"\\usr\\foo\\bar.lisp" =>
same as for unix, unless the lisp decided to upcase when parsing,
in which case the following is also acceptable:
#s(pathname :host yyy :directory '(:absolute "USR" "FOO")
:name "BAR" :type "LISP")
where xxx, yyy are the names of hosts of the appropriate type. I'm
ignoring issues of how one goes about creating a host of a particular
pathname type, which is indeed a portability problem -- especially if
you want to generate a pathname on a Lisp with one file system and read
it on a one with a different file system.
A couple of points:
1. I'm ignoring issues of empty or :unspecific components and how
make-pathname merges things like version and deviceq against
*default-pathname-defaults*. This is a whole other can of worms. I'm
just talking about case here.
2. Reading the #s(pathname ...) forms above should result in the
correct pathnames "under the same circumstances". For example, if read
in by two different implementations, both must define the hosts xxx and
yyy correctly. There is no attempt to be able to generate a windows
pathname on one system and than read it as an "equivalent" pathname on a
unix system. One could argue that one COULD do this if we used :case
:common, but I feel that this would be wrong. If someone creates a
windows pathname on one system and writes it to a file, then it should
be read back in as a windows pathname, not unix. If they want other
behavior, users should create what they want in code.
3. Although #s(pathname ... :type "LISP" :case :common) would always
mean the same thing, having #s(pathname ... :type "LSP") (implied :case
:local) produce the same thing in two different lisp systems depends on
both of them recognizing the same local conventions for short
extensions. This is a weakness.
4. It is indeed a problem if one windows system upcases local strings
when parsing and generates #s(pathname ...) with uppercase strings, if
the result is then read on a windows system which preserves case.
However, I think this is a problem anyway.
Another way of doing this would be to define some physical pathname
types (presumably classes), such as windows-pathname, unix-pathname,
etc., and have print-readably generate #s(windows-pathname ....),
#s(unix-pathname ...). Here we could use :common case by decree (no
make-pathname compatibility issues). This may be the best approach, as
it allows common case to be used easily, makes it easy to generate
readable pathnames in one Lisp and use them on another with a different
file system, etc. However, for this to be portable, it requires
extending the current spec, which #s(pathname ...) syntax does not.
---- No new comments below this line ----