Hi
there is a discussion going on the CMUCL mailing list
re. COMPILE-FILE-PATHNAME. The object of contention os the behavior
of C-F-P when the OUTPUT-FILE parameter is present and not NULL.
This is the current situation.
In CMUCL 18d you get:
* (compile-file-pathname "file.c" :output-file (make-pathname :type "o"))
#<Unprintable pathname, Host=#<COMMON-LISP::UNIX-HOST>, Device=NIL,
Directory=NIL, Name=NIL, Type="o", Version=NIL>
In ACL 6.x you get
CL-USER> (compile-file-pathname "file.c" :output-file (make-pathname :type "o"))
#p(:DIRECTORY (:ABSOLUTE "somewhere" "over" "therainbow") :TYPE "o")
In CLisp you get
[1]> (compile-file-pathname "file.c" :output-file (make-pathname :type "o"))
#P"file.o"
I don't remember what LW does, but it is similar to CMUCL.
Anyway, I beleive that the Clisp interpretation of the CLHS is (1)
correct and that (2) it is the most useful. And it also goes along
with my interpretation of the CLHS.
The passage in the CLHS is the following.
==============================================================================
The defaults for the output-file are taken from the pathname that
results from merging the input-file with the value of
*default-pathname-defaults*, except that the type component should
default to the appropriate implementation-defined default type for
compiled files.
==============================================================================
This is the definition of COMPILE-FILE-PATHNAME. The first sentence
seem to imply the CLisp interpretation, when we have NIL in the fields
of OUTPUT-PATHNAME. This is because of the sentence "The defaults
for".
Of ourse, since we are supplying the output pathname with an explicit
type, I interpret this as saying: the output PATHAME will have the
type I want.
I.e. The behavior of COMPILE-FILE-PATHANME is (at least)
(merge-pathnames <output-pathname>
(merge-pathnames <input-file> *default-pathname-defaults*))
Where <output-pathname> defaults to
(make-pathname :host nil
:device nil
:directory nil
:name nil
:type <implementation-dependent>
:version nil)
(I think this is right).
IMHO Clisp is right and everybody else is wrong.
To support my opinion, here is another example which would be allowed
under the CLisp interpretation, but not under other ones.
#+clisp
(compile-file-pathname (pathname "/bar/baz/foo.lisp")
:output-pathname (pathname "foo-clisp"))
=> #p"/bar/baz/foo-clisp.fas"
#+lispworks
(compile-file-pathname (pathname "/bar/baz/foo.lisp")
:output-pathname (pathname "foo-lw"))
=> #p"/bar/baz/foo-clisp.fsl"
#+acl
(compile-file-pathname (pathname "/bar/baz/foo.lisp")
:output-pathname (pathname "foo-acl"))
=> #p"/bar/baz/foo-acl.fsl"
#+cmu
(compile-file-pathname (pathname "/bar/baz/foo.lisp")
:output-pathname (pathname "foo-cmu"))
=> #p"/bar/baz/foo-cmu.fasl"
The alternative interpretations all revolve around doing very little
with the OUTPUT-FILE parameter is supplied and not null.
I.e. somthing along the lines of
(compile-file-pathname <input-file> :output-file <output-file>)
==
<output-file>
which would make this usage of COMPILE-FILE-PATHNAME pretty much
useless.
Any comments?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th 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 <·······@cs.nyu.edu> writes:
> Hi
Hi.
> there is a discussion going on the CMUCL mailing list
> re. COMPILE-FILE-PATHNAME. The object of contention os the behavior
> of C-F-P when the OUTPUT-FILE parameter is present and not NULL.
>
> This is the current situation.
Thorough as it is, I don't think this presentation is the right angle from
which to use the question.
The most important thing for compie-file-pathname to do is to predict what
compile-file will do. As such, looking at what various systems do is not the
way of knowing whether those implementations are right; rather, various systems
must assure that this function does what COMPILE-FILE does (IMO; I suppose it's
not written in the standard that way), and moreover, reverse implications
of COMPILE-FILE-PATHNAME in the spec must be applied back onto COMPILE-FILE.
> In CMUCL 18d you get:
>
> * (compile-file-pathname "file.c" :output-file (make-pathname :type "o"))
> #<Unprintable pathname, Host=#<COMMON-LISP::UNIX-HOST>, Device=NIL,
> Directory=NIL, Name=NIL, Type="o", Version=NIL>
I think this should be a printable pathname, but almost ok.
I think foo.o, not just .o, should be returned. But I don't mind that there
is no directory -- some implementations use no dir as working dir, others
don't.
> In ACL 6.x you get
>
> CL-USER> (compile-file-pathname "file.c" :output-file (make-pathname :type "o"))
> #p(:DIRECTORY (:ABSOLUTE "somewhere" "over" "therainbow") :TYPE "o")
I agree this should have :NAME "foo" though the change in dir seems ok to me.
> In CLisp you get
>
> [1]> (compile-file-pathname "file.c" :output-file (make-pathname :type "o"))
> #P"file.o"
Right.
> I don't remember what LW does, but it is similar to CMUCL.
>
> Anyway, I beleive that the Clisp interpretation of the CLHS is (1)
> correct and that (2) it is the most useful. And it also goes along
> with my interpretation of the CLHS.
I think so.
> The passage in the CLHS is the following.
>
> ==============================================================================
> The defaults for the output-file are taken from the pathname that
> results from merging the input-file with the value of
> *default-pathname-defaults*, except that the type component should
> default to the appropriate implementation-defined default type for
> compiled files.
> ==============================================================================
>
> This is the definition of COMPILE-FILE-PATHNAME. The first sentence
> seem to imply the CLisp interpretation, when we have NIL in the fields
> of OUTPUT-PATHNAME. This is because of the sentence "The defaults
> for".
>
> Of ourse, since we are supplying the output pathname with an explicit
> type, I interpret this as saying: the output PATHAME will have the
> type I want.
I do, too.
> I.e. The behavior of COMPILE-FILE-PATHANME is (at least)
>
> (merge-pathnames <output-pathname>
> (merge-pathnames <input-file> *default-pathname-defaults*))
>
> Where <output-pathname> defaults to
>
> (make-pathname :host nil
> :device nil
> :directory nil
> :name nil
> :type <implementation-dependent>
> :version nil)
>
> (I think this is right).
I agree.
> IMHO Clisp is right and everybody else is wrong.
For the stated values of "everybody else". I'm uncomfortable with universal
quantification.
> To support my opinion, here is another example which would be allowed
> under the CLisp interpretation, but not under other ones.
>
>
> #+clisp
> (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> :output-pathname (pathname "foo-clisp"))
> => #p"/bar/baz/foo-clisp.fas"
This set of examples is broken because it presupposes that
(pathname "foo-clisp")
means :name "foo-clisp" :type nil
when some implementations (notably Symbolics) make it be
:name "foo-clisp" :type :unspecific
I believe this second behavior is conforming. If one has this behavior,
your test cases won't be symmetric across platforms and so will be confusing.
Use MAKE-PATHNAME as above.
> #+lispworks
> (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> :output-pathname (pathname "foo-lw"))
> => #p"/bar/baz/foo-clisp.fsl"
>
> #+acl
> (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> :output-pathname (pathname "foo-acl"))
> => #p"/bar/baz/foo-acl.fsl"
>
> #+cmu
> (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> :output-pathname (pathname "foo-cmu"))
> => #p"/bar/baz/foo-cmu.fasl"
>
>
> The alternative interpretations all revolve around doing very little
> with the OUTPUT-FILE parameter is supplied and not null.
That may be true but doesn't matter.
> I.e. somthing along the lines of
>
> (compile-file-pathname <input-file> :output-file <output-file>)
> ==
> <output-file>
Yes, I can see that this is an alternate interpretation. I agree with you
it is not desired.
> which would make this usage of COMPILE-FILE-PATHNAME pretty much
> useless.
No, I don't agree that this would make COMPILE-FILE-PATHNAME useless.
WHATEVER the choice of merging rules, C-F-P is there to make sure you don't
have to know them.
You might be saying that C-F-P wouldn't have been in the standard at all if
the action were this trivial, and that might be right. But that's a weak
justification. (I had a class in Solid State Chemistry once where I'd left
my calculator at home and couldn't compute the answer numerically so I just
wrote out the algorithm for finding the solution and then also noted that,
anyway, of the three choices offered us, we had one too few data points to
distinguish between choice A and B, so the answer had to be choice C. I got
no points for the answer, even though it was right ... Well, ok, I probably
should have gotten full credit, and maybe you should too here, but life is
harsh sometime. This is not the route to go down in this reasoning...)
> Any comments?
I think you're basically right in your reading.
Then again, my opinion is just my opinion. But you knew that.
Kent M Pitman <······@world.std.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Hi
>
> Hi.
>
> > there is a discussion going on the CMUCL mailing list
> > re. COMPILE-FILE-PATHNAME. The object of contention os the behavior
> > of C-F-P when the OUTPUT-FILE parameter is present and not NULL.
> >
> > This is the current situation.
>
> Thorough as it is, I don't think this presentation is the right angle from
> which to use the question.
Ok.
>
> The most important thing for compie-file-pathname to do is to predict what
> compile-file will do. As such, looking at what various systems do is not the
> way of knowing whether those implementations are right; rather, various systems
> must assure that this function does what COMPILE-FILE does (IMO; I suppose it's
> not written in the standard that way), and moreover, reverse implications
> of COMPILE-FILE-PATHNAME in the spec must be applied back onto
> COMPILE-FILE.
Somehow it is implied in the spec for C-F-P when implementation dependent
keyword parameters are discussed.
> > In CMUCL 18d you get:
> >
> > * (compile-file-pathname "file.c" :output-file (make-pathname :type "o"))
> > #<Unprintable pathname, Host=#<COMMON-LISP::UNIX-HOST>, Device=NIL,
> > Directory=NIL, Name=NIL, Type="o", Version=NIL>
>
> I think this should be a printable pathname, but almost ok.
>
> I think foo.o, not just .o, should be returned. But I don't mind that there
> is no directory -- some implementations use no dir as working dir, others
> don't.
Well, the lack of the `name' is the object of contention here. As for
the directory, that would depend on the content of *DEFAULT-PATHNAME-DEFAULTS*.
...
>
> > IMHO Clisp is right and everybody else is wrong.
>
> For the stated values of "everybody else". I'm uncomfortable with universal
> quantification.
Ok. I have to be more careful (unless, of course, I am debating
Scheme :) ).
>
> > To support my opinion, here is another example which would be allowed
> > under the CLisp interpretation, but not under other ones.
> >
> >
> > #+clisp
> > (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> > :output-pathname (pathname "foo-clisp"))
> > => #p"/bar/baz/foo-clisp.fas"
>
> This set of examples is broken because it presupposes that
> (pathname "foo-clisp")
> means :name "foo-clisp" :type nil
> when some implementations (notably Symbolics) make it be
> :name "foo-clisp" :type :unspecific
Yes. I knew that the :UNSPECIFIC default may creep in in my reading,
I just did not quite know how it would impact in my interpretations.
> I believe this second behavior is conforming. If one has this behavior,
> your test cases won't be symmetric across platforms and so will be confusing.
> Use MAKE-PATHNAME as above.
>
> > #+lispworks
> > (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> > :output-pathname (pathname "foo-lw"))
> > => #p"/bar/baz/foo-clisp.fsl"
> >
> > #+acl
> > (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> > :output-pathname (pathname "foo-acl"))
> > => #p"/bar/baz/foo-acl.fsl"
> >
> > #+cmu
> > (compile-file-pathname (pathname "/bar/baz/foo.lisp")
> > :output-pathname (pathname "foo-cmu"))
> > => #p"/bar/baz/foo-cmu.fasl"
> >
> >
> > The alternative interpretations all revolve around doing very little
> > with the OUTPUT-FILE parameter is supplied and not null.
>
> That may be true but doesn't matter.
>
> > I.e. somthing along the lines of
> >
> > (compile-file-pathname <input-file> :output-file <output-file>)
> > ==
> > <output-file>
>
> Yes, I can see that this is an alternate interpretation. I agree with you
> it is not desired.
>
> > which would make this usage of COMPILE-FILE-PATHNAME pretty much
> > useless.
>
> No, I don't agree that this would make COMPILE-FILE-PATHNAME useless.
> WHATEVER the choice of merging rules, C-F-P is there to make sure you don't
> have to know them.
I kind of disagree. IMHO the spec says quite clearly what is the
sequence of calls to MERGE-PATHNAMES that must be performed. What is
hidden is the type field that is chosen and the original
implementation dependent setup of *D-P-D*.
> You might be saying that C-F-P wouldn't have been in the standard at all if
> the action were this trivial, and that might be right.
Oh no. I am not saying that. I can see that C-F-P is a very useful
thing. I can come up with a lot of justifications for it. :)
...
>
> > Any comments?
>
> I think you're basically right in your reading.
>
> Then again, my opinion is just my opinion. But you knew that.
Well, opinions gather consensus and consensus is what moves things.
Even when the consensus is not what we like, but life is harsh
sometimes :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th 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 <·······@cs.nyu.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
...
> > > I.e. somthing along the lines of
> > >
> > > (compile-file-pathname <input-file> :output-file <output-file>)
> > > ==
> > > <output-file>
> >
> > Yes, I can see that this is an alternate interpretation. I agree with you
> > it is not desired.
> >
> > > which would make this usage of COMPILE-FILE-PATHNAME pretty much
> > > useless.
> >
> > No, I don't agree that this would make COMPILE-FILE-PATHNAME useless.
> > WHATEVER the choice of merging rules, C-F-P is there to make sure you don't
> > have to know them.
>
> I kind of disagree.
No, [I think] you don't. You just didn't understand what I said. I
didn't disagree with your conclusion, just this particular stated
reason (that is, I disagree that it's relevant whether c-f-p is made
useless by any particular semantics; I didn't mean that it didn't
matter what the particular semantics were).
> IMHO the spec says quite clearly what is the
> sequence of calls to MERGE-PATHNAMES that must be performed. What is
> hidden is the type field that is chosen and the original
> implementation dependent setup of *D-P-D*.
Certainly. I didn't disagree with this. ;)
> > You might be saying that C-F-P wouldn't have been in the standard at all if
> > the action were this trivial, and that might be right.
>
> Oh no. I am not saying that. I can see that C-F-P is a very useful
> thing. I can come up with a lot of justifications for it. :)
(Above you seemed to imply that whether it was useful was useful. Heh...)
> ...
> >
> > > Any comments?
> >
> > I think you're basically right in your reading.
> >
> > Then again, my opinion is just my opinion. But you knew that.
>
> Well, opinions gather consensus and consensus is what moves things.
> Even when the consensus is not what we like, but life is harsh
> sometimes :)
I'll give you that. Anyway, I believe we're in agreement on the technical
matters and merely were uselessly sparring (due to me, perhaps) on minor
and inconsequential points of philosophy and/or proof technique.
I'd be interested to hear any counter-views that are offered on the CMU
debate you're having, since while I generally acknowledge these issues
can have alternate points of view, I don't really see (without help)
what the alternate point of view IS here. Obviously, we see some
implementations that do something we didn't expect, but sometimes code does
things we don't expect because no one thought hard at all and no one has
a principled point of view on things. Has any vendor presented with the
info that you have cited actually said "no, you're wrong"? I'll be surprised
but interested if they have.
Kent M Pitman <······@world.std.com> writes:
...
> > Well, opinions gather consensus and consensus is what moves things.
> > Even when the consensus is not what we like, but life is harsh
> > sometimes :)
>
> I'll give you that. Anyway, I believe we're in agreement on the technical
> matters and merely were uselessly sparring (due to me, perhaps) on minor
> and inconsequential points of philosophy and/or proof technique.
Yep. Let's clear that.
> I'd be interested to hear any counter-views that are offered on the CMU
> debate you're having, since while I generally acknowledge these issues
> can have alternate points of view, I don't really see (without help)
> what the alternate point of view IS here. Obviously, we see some
> implementations that do something we didn't expect, but sometimes code does
> things we don't expect because no one thought hard at all and no one has
> a principled point of view on things. Has any vendor presented with the
> info that you have cited actually said "no, you're wrong"? I'll be surprised
> but interested if they have.
The debate on the CMUCL list was brief. I decided to bring the matter
over here to give it wider visibility. I have not contacted the
vedors directly. All in all this seemed an across the board matter.
I am sure the folks in the Common Lisp Houses will look into the matter.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th 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'.
From: Pekka P. Pirinen
Subject: Re: CLHS Hermeneutics: COMPILE-FILE-PATHNAME behavior.
Date:
Message-ID: <uheig3pnj.fsf@globalgraphics.com>
> I don't remember what LW does, but it is similar to CMUCL.
It only merges the name, and then only if output-file is a
directory.
> IMHO Clisp is right and everybody else is wrong.
I agree. All I can say is that the COMPILE-FILE code in the other
implementations no doubt predates that specification.
--
Pekka P. Pirinen
"You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists." - Abbie Hoffman