Greetings, and thanks so much for the feedback.
It does seem one other user requested this as well. I do not think our
behavior violates the spec, but it does vary from other popular
implementations.
In short, the first '.' terminates the name in GCL. This was convenient
in our implementation of pathnames using the regex (e.g. regular
expression) engine which has been in GCL for ages. As these follow a
left to right algorithm (longest match if I recall), it makes sense to
define a terminating character sequence.
If interested you can peruse lsp/gcl_make_pathname.lsp, where you will find
(defconstant +physical-pathname-defaults+ '(("" "" "" "")
("" "" "" "")
("" "(/?([^/]+/)*)" "" "" ""
"([^/]+/)" "/" "/")
("" "([^/.]*)" "" ".")
("." "(\\.[^/]*)?" "" "")
("" "" "" "")))
and an analog for logical pathnames that govern the parsing. I can
describe the role of each string in the group if interested.
I will try to look at the already implemented regex engine to see if a
negative look-ahead could be supported.
Take care,
Matt Kaufmann <[email protected]> writes:
> Hi Camm,
>
> Here's a request: Could you arrange that for any file with a name of the
> form "<name>.lisp", then its pathname-name is "<name>" and its
> pathname-type is "lisp"? This is not always the case, at least in my
> version of GCL 2.7.1, when "<name>" contains a dot (i.e., character
> #\.).
>
> Below I explain further what I'm seeing and why this is a problem for
> ACL2. (Probably one can imagine a similar problem for other systems.)
>
> Here is behavior I'm seeing in GCL 2.7.1, which causes a problem for
> ACL2 as explained below.
>
>>(pathname-name (pathname "foo.xyz.lisp"))
>
> "foo"
>
>>(pathname-name "foo.xyz.lisp")
>
> "foo"
>
>>(pathname-type (pathname "foo.xyz.lisp"))
>
> "xyz.lisp"
>
>>(pathname-type "foo.xyz.lisp")
>
> "xyz.lisp"
>
>>
>
> I'd prefer to see the behavior shown in the following example, i.e.,
> returning a pathname-type of "lisp".
>
>>(pathname-name "foo-xyz.lisp")
>
> "foo-xyz"
>
>>(pathname-type "foo-xyz.lisp")
>
> "lisp"
>
>>
>
> I'm not sure this behavior is in error, by the way -- just surprising
> (to me) and, in the case of ACL2, inconvenient. Here's what I found
> in the CL HyperSPec.
>
> https://www.lispworks.com/documentation/HyperSpec/Body/19_bae.htm
>
> 19.2.1.5 The Pathname Type Component
>
> Corresponds to the ``filetype'' or ``extension'' concept in many
> host file systems. This says what kind of file this is. This
> component is always a string, nil, :wild, or :unspecific.
>
> To me, it is natural to view "foo.xyz.lisp" as a lisp file, hence with
> extension "lisp" to say that the "kind of file" is a lisp file.
>
> This gets in the way for ACL2 in the case of the following two books.
>
> books/projects/aleo/vm/circuits/axe/blake2s1round.old.lisp
> books/projects/aleo/vm/circuits/axe/blake2s1round.lisp
>
> When we do certifications in parallel (i.e., with -j greater than 1),
> compilation can be attempted in parallel. The two books above can
> thus lead to the following calls done by two GCL processes in
> parallel.
>
> (COMPILE-FILE
>
> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/[email protected]"
> :OUTPUT-FILE
> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.o")
>
> (COMPILE-FILE
> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.lsp"
> :OUTPUT-FILE
> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.o")
>
> Both of these compilations attempt to create the same file,
> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.data".
> I suspect that if pathname-name were changed as described above, then
> the first compile-file call above would instead create
> "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.data".
>
> Thanks,
> Matt
>
--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
