is
(apply #'make-pathname :defaults path args)
the same as
(merge-pathnames (apply #'make-pathnames args) path)
e.g., (make-pathname :name "a" :type nil :defaults #p"b.c")
should return #p"a.c" (if YES) or #p"a" (if NO)?
An argument could be made both ways and implementations differ
(some, such as allegro, cmucl, cormanlisp and lispworks,
return #p"a" and others, like clisp, return #p"a.c").
CLHS for make-pathname says:
After the components supplied explicitly by host, device, directory,
name, type, and version are filled in, the
merging rules used by merge-pathnames are used to fill in any unsupplied
components from the defaults
supplied by defaults.
the problem is that when we supply NIL to make-pathname, subsequent
merge-pathname will interpret it as unsupplied and will replace it.
so, what was the x3j13's intent here?
Sent via Deja.com http://www.deja.com/
Before you buy.
···@usa.net writes:
> is
> (apply #'make-pathname :defaults path args)
> the same as
> (merge-pathnames (apply #'make-pathnames args) path)
>
> e.g., (make-pathname :name "a" :type nil :defaults #p"b.c")
> should return #p"a.c" (if YES) or #p"a" (if NO)?
>
> An argument could be made both ways and implementations differ
> (some, such as allegro, cmucl, cormanlisp and lispworks,
> return #p"a" and others, like clisp, return #p"a.c").
>
> CLHS for make-pathname says:
>
> After the components supplied explicitly by host, device, directory,
> name, type, and version are filled in, the
> merging rules used by merge-pathnames are used to fill in any unsupplied
> components from the defaults
> supplied by defaults.
>
> the problem is that when we supply NIL to make-pathname, subsequent
> merge-pathname will interpret it as unsupplied and will replace it.
>
> so, what was the x3j13's intent here?
No one on x3j13 can speak for x3j13's intent, as a matter of policy.
The document speaks for itself.
However, my informal recollection of the difference (and I'm not looking
at the spec as I write this) is that the difference is in the handling of
NIL's--that
(pathname-type (make-pathname :name "foo" :type nil
:defaults (make-pathname :name "foo" :type "bar")))
=> NIL
while
(pathname-type (merge-pathnames (make-pathname :name "foo" :type nil)
(make-pathname :name "foo" :type "bar")))
=> "bar"
The issue is in now you understand "unsupplied". In the context of
MAKE-PATHNAME, most people interpret unsupplied to mean not the
meaning you'd make it for pathnames, but for argument-passing. That is,
NIL is supplied (its supplied-p argument is true).
There is room for an implementation to differ, so I can't say an implementation
that didn't do what I say above is non-conforming, but most people I know
agree informally that if you don't have access to the above behavior, you
have a much harder time constructing certain pathnames without doing
manual merging.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> ···@usa.net writes:
>
> most people I know agree informally that if
> you don't have access to the above behavior, you
> have a much harder time constructing certain
> pathnames without doing
> manual merging.
Thanks!
(CLISP now complies with this common understanding)
A related question is how one should interpret pathnames like
#p".bashrc". CMUCL and Allegro interpret it as (make-pathname :type nil
:name ".bashrc"), while CLISP and GCL interpret it as (make-pathname
:name nil :type "bashrc"). CLHS appears to be silent on the matter,
but, personally, I would consider the first behavior more useful.
What do you think?
Sent via Deja.com http://www.deja.com/
Before you buy.
In article <············@nnrp1.deja.com>, <···@usa.net> wrote:
>A related question is how one should interpret pathnames like
>#p".bashrc". CMUCL and Allegro interpret it as (make-pathname :type nil
>:name ".bashrc"), while CLISP and GCL interpret it as (make-pathname
>:name nil :type "bashrc"). CLHS appears to be silent on the matter,
>but, personally, I would consider the first behavior more useful.
>
>What do you think?
The CL specification leaves parsing of OS-specific pathnames up to the
implementator; it would be impossible for it to define rules that would
apply universally. Unix dot-filenames have always been a conundrum, since
they don't really fit the generic <name><delimiter><type> model. I think
Symbolics (whose pathname system the CL pathname system was modeled after)
may even have changed how they interpreted it at one time.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <············@nnrp1.deja.com>, <···@usa.net> wrote:
>
> >A related question is how one should interpret pathnames like
> >#p".bashrc". CMUCL and Allegro interpret it as (make-pathname :type nil
> >:name ".bashrc"), while CLISP and GCL interpret it as (make-pathname
> >:name nil :type "bashrc"). CLHS appears to be silent on the matter,
> >but, personally, I would consider the first behavior more useful.
Yes, it intentionally takes no position. I apologize, though, for it
not doing what we came to call "being explicitly vague". The "implicitly
vague" style is annoying because you never know when to stop searching.
This has been a known problem ever since forever. Well, since the design
of the original pathname model on the Lisp Machine, certainly, which
influenced the original CLTL design (even if not as much as it perhaps
should have...)
> >What do you think?
>
> The CL specification leaves parsing of OS-specific pathnames up to the
> implementator; it would be impossible for it to define rules that would
> apply universally. Unix dot-filenames have always been a conundrum, since
> they don't really fit the generic <name><delimiter><type> model. I think
> Symbolics (whose pathname system the CL pathname system was modeled after)
> may even have changed how they interpreted it at one time.
I concur with Barry on this. It's definitely something for which an
OS-binding and not the overall standard has to speak. That's why it's
left to the individual implementation, because only that
implementation knows what its external constraints are. A
posix-binding specifying a lot of detail for that style file system
would be handy, of course.
Btw, I might argue that .bashrc should be
:name "bash" :type :init
Or maybe :type :invisible.
That is, one could argue that it was idiosyncratically the case that the
name follows, rather than precedes, the type in this case. And one might
want to designate a distinguished keyword for this meaning since
:type ""
would not be very informative (not to mention already being needed for
filenames like "foo."). This would also let someone do
(directory (make-pathname :name :wild :type :invisible))
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>I concur with Barry on this. It's definitely something for which an
>OS-binding and not the overall standard has to speak. That's why it's
>left to the individual implementation, because only that
>implementation knows what its external constraints are. A
>posix-binding specifying a lot of detail for that style file system
>would be handy, of course.
I suggested something like this way back when, but there was little
interest in pursuing it. I think the prevailing opinion may have been that
it's the job of the OS standardization committees to define their APIs in
various languages. But I knew that the POSIX committee would be very
unlikely to bother defining the CL-POSIX API (AFAIK, they haven't even
bothered with a C++ API, they just expect C++ to use the C interface); if
it was going to happen, it would have to come from the Lisp community, not
the POSIX community.
>Btw, I might argue that .bashrc should be
> :name "bash" :type :init
Interesting idea. For this type of thing to work, the Lisp implementation
would have to have a list of all the ideosyncratic init-file naming
conventions. It can't just use a simple mapping to .<name>rc, except
perhaps as a default fall-back, because Emacs's init file is just .emacs,
not .emacsrc, and sh's init file is .profile.
I'm not sure that the pathname system was ever intended to perform such
contortions, except perhaps for logical pathnames (since their stated
purpose is to map ideosyncratic pathnames to a common scheme).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> >Btw, I might argue that .bashrc should be
> > :name "bash" :type :init
>
> Interesting idea. For this type of thing to work, the Lisp implementation
> would have to have a list of all the ideosyncratic init-file naming
> conventions. It can't just use a simple mapping to .<name>rc, except
> perhaps as a default fall-back, because Emacs's init file is just .emacs,
> not .emacsrc, and sh's init file is .profile.
>
> I'm not sure that the pathname system was ever intended to perform such
> contortions, except perhaps for logical pathnames (since their stated
> purpose is to map ideosyncratic pathnames to a common scheme).
Well, the Lisp Machine did have "canonical types", such that :type
:lisp would select .lisp or .lsp as appropriate to the host file
system. It also manages case correctly (that is, .LSP or .LISP in VAX
and TOPS-20, where both cases are available but uppercase dominates).
Such rewrites are not as extreme as what I suggested with inits, but
it does show name rewriting was part of the original design--at least,
the original LispM design, from which (as you know) the CL design descended.
As you surely also know, CL chose not to pick that part of the
pathname spec up. As a consequence, therefore, as we've all seen,
it's a pain in the neck to write code that detects fasl files that
need to be compiled because there is not :type :fasl that you can
probe for... just one of many instances of the problem.
However, the spec does leave enormous latitude to vendors on how they
do their mapping. I vaguely recall a ENUNICE (unix emulation for
vax?) lisp (perhaps not a CL, but perhaps something that informed this
decision) which rewrote capital "X" as "$X" in the file system to give
the illusion of upper and lowercase filenames to lisp programs. One
would never want to standardize on that in the language, but my point
is that implementations often have specialized needs that only their
implementors understand; absent OS-related or filessytem-related
bindings to guide them, they have to do the best they can for their
users.
Kent M Pitman <······@world.std.com> writes:
> it's a pain in the neck to write code that detects fasl files that
> need to be compiled because there is not :type :fasl that you can
> probe for... just one of many instances of the problem.
But isn't this particular instance solved by the function
COMPILE-FILE-PATHNAME ?
Allegro (Unix):
(compile-file-pathname "foo") => #p"foo.fasl"
MCL:
(compile-file-pathname "foo") => #p"foo.pfsl"
etc.
Of course, this solves only this instance of the problem. There is
still the problem of whether source files end in ".lisp" or ".lsp" which
(it seems) can be finessed by omitting it from calls to COMPILE-FILE or
LOAD...
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu