Hi,
I've been trying to construct a pathname in clisp that has all the
components except name and type. I believe the standard way of doing this is
(make-pathname :name nil :type nil :defaults #p"/foo/bar.baz")
This in clisp evaluates to
#p"/foo/bar.baz"
Have I misunderstood the standard?
S
Sunil Mishra wrote:
> I've been trying to construct a pathname in clisp that has all the
> components except name and type. I believe the standard way of doing this is
>
> (make-pathname :name nil :type nil :defaults #p"/foo/bar.baz")
>
> This in clisp evaluates to
>
> #p"/foo/bar.baz"
>
> Have I misunderstood the standard?
The dictionary entry for make-pathname 19.4.4 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 rules for merging are essentially that nil values are eligible
for replacement by merging, but :unspecific is not. See
"19.2.2.2.3.1 Relation between component values NIL and :UNSPECIFIC". Therefore, you might want to do something like the following instead:
(make-pathname :name :unspecific :type :unspecific
:defaults #p"/foo/bar.baz")
Now, you haven't really explained _why_ you want to construct
this particular pathname, but if your intent is that later you
can merge specific name and type using this pathname as a default,
you can still do something like:
(merge-pathnames #p"turing.lisp" my-default)
because :unspecific fields in the default (2nd arg) will be
overridden by explicit non-nil values in the 1st arg.
But see "19.2.2.2.3 :UNSPECIFIC as a Component Value" which cautions
that :unspecific might not be allowed by all implementations.
It seems to warn against a portable program using :unspecific:
Whether a value of :unspecific is permitted for any component on
any given file system accessible to the implementation is implementation-defined. A conforming program must never
unconditionally use a :unspecific as the value of a pathname
component because such a value is not guaranteed to be permissible
in all implementations.
but I don't think this is the intended meaning. My interpretation
is that :unspecific must always be supported in the pathname
calculus performed by make-pathname, translate-pathname,
merge-pathnames, etc. It is only when a pathname is passed to some
function that accesses an actual filesystem (e.g. open) that the
implementation-specific question arises whether such a pathname may
contain :unspecific in any particular field.
"Steven M. Haflich" <·······@pacbell.net> writes:
> Sunil Mishra wrote:
> > I've been trying to construct a pathname in clisp that has all the
> > components except name and type. I believe the standard way of doing this is
> >
> > (make-pathname :name nil :type nil :defaults #p"/foo/bar.baz")
> >
> > This in clisp evaluates to
> >
> > #p"/foo/bar.baz"
> >
> > Have I misunderstood the standard?
No, the CLISP implementers did. It's a subtle design.
> The dictionary entry for make-pathname 19.4.4 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.
>
> [...] Therefore, you might want to do something like the
> following instead:
>
> (make-pathname :name :unspecific :type :unspecific
> :defaults #p"/foo/bar.baz")
That shouldn't be necessary, since the name and type components are
definitely supplied, so the merging rules are not used.
> But see "19.2.2.2.3 :UNSPECIFIC as a Component Value" which cautions
> that :unspecific might not be allowed by all implementations.
> It seems to warn against a portable program using :unspecific:
> [quote omitted]
Yes, and the note for MAKE-PATHNAME is even more direct:
Portable programs should not supply :unspecific for any component.
> but I don't think this is the intended meaning. My interpretation
> is that :unspecific must always be supported in the pathname
> calculus performed by make-pathname, translate-pathname,
> merge-pathnames, etc. It is only when a pathname is passed to some
> function that accesses an actual filesystem (e.g. open) that the
> implementation-specific question arises whether such a pathname may
> contain :unspecific in any particular field.
That would have been the reasonable way to design it, but the intent
of the standard is clear: you just can't specify :UNSPECIFIC and be
portable. Later on in the same section, it actually says
When writing[1] the value of any pathname component, the
consequences are undefined if :unspecific is given for a pathname in
a file system for which it does not make sense.
The best we can hope for is that no implementation actually complains
about it. LW won't.
Because the standard doesn't guarantee the existence of a portable
pathname calculus (see section 19.2.2.5 Restrictions on Constructing
Pathnames), it's basically impossible to write portable pathname
manipulation code (as opposed to just using pathnames to refer to
files). And even if one just plunges in and hopes that the
implementations don't actually signal errors about any restrictions,
the standard leaves so much undefined about truenames and matching
rules, that there's still a lot of porting work for any interesting
program.
--
Pekka P. Pirinen
Those who do not understand Lisp are doomed to reimplement it.
- Erik Naggum <erik_naggum.no>
In article <················@everest.com>,
Sunil Mishra <············@everest.com> wrote:
> Hi,
>
> I've been trying to construct a pathname in clisp that has all the
> components except name and type. I believe the standard way of doing
this is
>
> (make-pathname :name nil :type nil :defaults #p"/foo/bar.baz")
>
> This in clisp evaluates to
>
> #p"/foo/bar.baz"
>
> Have I misunderstood the standard?
no. this is a bug in clisp.
it has been fixed some months ago in the CVS repository.
Sent via Deja.com http://www.deja.com/
Before you buy.