This is invalid as a pathname to an actual file, only valid as something that you can merge with a pathname that has a type: (make-pathname :directory directory :name "typed-file.type" :type nil)
Conversely, this is probably not a good idea for naming a file to load, as many implementations will add a type of .lisp or .lsp (or .fas) before trying to load such a file: (make-pathname :directory directory :name "untyped-file" :type nil) Or maybe they shouldn't? Not clear from the spec, but common practice is there.
In other words, you need a different set of valid values for static-file and file components (though there might be a common subset).
Can you work on the test as now part of the official testsuite?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] When everything seems to be going against you, remember that the airplane takes off against the wind, not with it. — Henry Ford
good morning;
[ the context for this message is not clear. ]
On 2010-03-16, at 06:33 , Faré wrote:
This is invalid as a pathname to an actual file, only valid as something that you can merge with a pathname that has a type: (make-pathname :directory directory :name "typed-file.type" :type nil)
"this" is a file without a type?
Conversely, this is probably not a good idea for naming a file to load, as many implementations will add a type of .lisp or .lsp (or .fas) before trying to load such a file: (make-pathname :directory directory :name "untyped-file" :type nil)
all implementations are permitted to use an incomplete specification to designate any extant source and/or binary file and load one of them.[0] that passage leaves questions unanswered: - (stated explicitly) which typed filed to load. - (unstated) what is the consequence if an untyped file exists as well as one or more typed ones.
it does not permit to not load an untyped file if that is the only one which exists.
Or maybe they shouldn't? Not clear from the spec, but common practice is there.
i read nothing in the text which permits to require a type.
In other words, you need a different set of valid values for static-file and file components (though there might be a common subset).
given the definition for load, a source file component should be able to designate a file without a type. is there some other distinction?
Can you work on the test as now part of the official testsuite?
in principle, ok.
--- [0] : http://www.lispworks.com/documentation/HyperSpec/Body/ f_load.htm#load
On 16 March 2010 11:41, james anderson james.anderson@setf.de wrote:
This is invalid as a pathname to an actual file, only valid as something that you can merge with a pathname that has a type: (make-pathname :directory directory :name "typed-file.type" :type nil)
"this" is a file without a type?
I haven't really been following, but I hope I'm sufficiently on track to understand the confusion.
One of the core problems (or features, if you like) in CLHS pathname specification is the requirement for
Pathname <-> Namestring
translations to be information preserving.
From this is follows (at least by IMO reasonable attempts to treat
pathnames with any consistency) that EITHER there are pathnames for which no namestring exists OR that namestring syntax no longer even remotely resembles the native namestring syntax of the platform -- which is generally speaking a lossy idea since the standard does not provide a NATIVE-NAMESTRING function.
So, we can reasonably say
(make-pathname :name "foo" :type nil) <-> "foo"
and
(make-pathname :name "foo" :type "bar") <-> "foo.bar"
but even an apparently innocent things like
(make-pathname :name "foo.tar" :type "gz") (make-pathname :name "foo" :type "tar.gz")
are wrought with difficulty.
For Common Lisp these are two non-equal pathnames, so the namestrings --if they exist-- should be non-equal.
SBCL takes the stance that the first one has the namestring "foo.tar.gz", and that the second one has no namestring -- another implementation could take the opposite stance, though I freely submit that IMO disallowing dots in types is less problematic than disallowing them in names.
The issue with (make-pathname :name "foo.bar" :type nil) is identical.
Cheers,
-- Nikodemus
good morning
On 2010-03-16, at 11:20 , Nikodemus Siivola wrote:
[ ... ] (make-pathname :name "foo.tar" :type "gz") (make-pathname :name "foo" :type "tar.gz")
are wrought with difficulty.
For Common Lisp these are two non-equal pathnames, so the namestrings --if they exist-- should be non-equal.
SBCL takes the stance that the first one has the namestring "foo.tar.gz", and that the second one has no namestring -- another implementation could take the opposite stance, though I freely submit that IMO disallowing dots in types is less problematic than disallowing them in names.
my experience was that sbcl takes the stance that neither one has a namestring. i endeavored to formulate the tests such that they do not depend on the existence of such namestrings.
The issue with (make-pathname :name "foo.bar" :type nil) is identical.
Cheers,
-- Nikodemus
-
Faré -
james anderson -
Nikodemus Siivola