The Horror! (Yep: Common Lisp Pathnames)

[marcoxa]

Hi

I got the crazy idea to port another old thing to Interlisp CL.

Alas, the pathnames are not CL compliant. The culprit is the :directory component that is an opaque structure and not a list.

Question: how would you build a "layer" on top of - at least - the pathnames? That is, what would you do (apart from building a full ANSICL package etc etc.)

Thanks

MA

[pamoroso]

A possible approach may be something like Peter Seibel's portable pathname library.

[marcoxa]

Yep. That's a way to do it.

[masinter]

This is one of the few things that changed between CLtL 2 and ANSI Common Lisp; see https://interlisp.org/clhs/Issues/iss263_w.htm

[marcoxa]

Yes, that is clear, but how do you get a list out of the directory structure? You parse the string?

[tfeb]

On 10 May 2026, at 11:45, Marco Antoniotti ***@***.***> wrote:Alas, the pathnames are not CL compliant. The culprit is the :directory component that is an opaque structure and not a list. 'some other object defined by the implementation to be a valid directory component.': so anything is valid there. I think make-pathname needs to accept a list, but pathname directory doesn't have to return one.Message ID: ***@***.***>

[marcoxa]

F*CK! I did miss the glossary entry in the ANSI spec.

[masinter]

issue PATHNAME-SUBDIRECTORY-LIST email discussion can be found here: [pathname-subdirectory-list mail](https://github.com/user-attachments/files/28903081/pathname-subdirectory-list.mail.txt)

[marcoxa]

Yes. Thanks.

But the question remains.

How do I get

42> (pathpkg:munge-il-directory-component *default-pathname-defaults*)
(:ABSOLUTE "Users" "me" "somewhere" "in" "the" "filesystem")

?
Thanks.

[masinter]

i've lost track of where we are on this. Perhaps with all of the background now, you might restate what problem you want to solve? Are you having trouble connecting pathnames to files?
Or just looking for a project to help out?

[marcoxa]

Hi I am fooling around with Medley and I was entertaining the idea to port some Common Lisp to it. Apart the problem of figuring out how to "edit" "files" (but that's my problem; I will bother you guys about this later on), there was the initial problem of the wrong package used by CL:LOAD (which, I understand, can be fixed) and, above all there is the issue of (make-pathname :directory '(:absolute "foo" "bar")) not working (even for CLtL2). make-pathname must accept that :directory argument. In reverse, it is not clear to me how to obtain the (:absolute "foo" "bar") from the object returned by pathname-directory. I am sure that, in general, there is a lot of CLtL2-fying to be done, not to speak of ANSI-fying. All the best Marco

…

On Mon, May 25, 2026 at 7:33 PM Larry Masinter ***@***.***> wrote: i've lost track of where we are on this. Perhaps with all of the background now, you might restate what problem you want to solve? Are you having trouble connecting pathnames to files? Or just looking for a project to help out? — Reply to this email directly, view it on GitHub <#2601?email_source=notifications&email_token=AAD5SWWDN5MHBYOAW5F6AZ344R7WRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQGUZDKOJTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17052593>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5SWTV5J6HUZWFKJO57K344R7WRAVCNFSM6AAAAACYX5QJZWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBVGI2TSMY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Marco Antoniotti Somewhere over the Rainbow

[masinter]

I think what is going on is that there are several different approaches to pathname-directory that Medley could take: CLtL 1, CLtL 2, ANSII, Medley-compatible, sbcl, ... out of which we need to choose what will Medley do. This is independent of any other Medley components or what Interlisp funtions do when handed non-PATHNAMEP values; we could improve interoperability between Medley and (some) other CL implementations by choosing to be compatible with sbcl.

sbcl
(make-pathname :directory "a/b/c") returns #P"/a/b/c/")
(pathname-directory #P"/a/b/c/") returns (:absolute "a" "b" "c")

[marcoxa]

Hi AFAIAC the optimum is ANSI. As I ranted here <https://within-parens.blogspot.com/2022/01/my-list-of-common-lisp-libraries-and-sw.html> some time ago, I am very annoyed by the libraries that "work on SBCL"; my libraries are 99% portable across implementations. Going back to the `MAKE-PATHNAME` issue, this is what ANSI implementations do. Correctly. ```lisp CL-USER 1 > (make-pathname :directory "a/b/c") #P"/a/b/c/" CL-USER 2 > (describe *) #P"/a/b/c/" is a PATHNAME HOST NIL DEVICE NIL DIRECTORY (:ABSOLUTE "a/b/c") NAME NIL TYPE NIL VERSION NIL ``` In fact, ANSI is very specific for this case: If the *directory* is a *string*, it should be the name of a top level directory, and should not contain any punctuation characters; that is, specifying a *string*, *str*, is equivalent to specifying the list `(:absolute` *str*`)`. Specifying the symbol `:wild` is equivalent to specifying the list `(:absolute :wild-inferiors)`, or `(:absolute :wild)` in a file system that does not support :wild-inferiors. Therefore, SBCL is (mostly) wrong on this bit (CCL and ACL as well; LW, ECL, ABCL are ... more right). Apart from that, how do I get the `PATH` field out of an `IL:DIRECTORY-COMPONENT`? Thanks MA

…

On Thu, May 28, 2026 at 10:20 PM Larry Masinter ***@***.***> wrote: I think what is going on is that there are several different approaches to pathname-directory that Medley could take: CLtL 1, CLtL 2, ANSII, Medley-compatible, sbcl, ... out of which we need to choose what will Medley do. This is independent of any other Medley components or what Interlisp funtions do when handed non-PATHNAMEP values; we could improve interoperability between Medley and (some) other CL implementations by choosing to be compatible with sbcl. sbcl (make-pathname :directory "a/b/c") returns #P"/a/b/c/") (pathname-directory #P"/a/b/c/") returns (:absolute "a" "b" "c") — Reply to this email directly, view it on GitHub <#2601?email_source=notifications&email_token=AAD5SWRMFMGJ3IQKBGXSD7T45CNPHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQHE3DQMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17096822>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5SWWK4Y7WURG7SRP3O2L45CNPHAVCNFSM6AAAAACYX5QJZWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBZGY4DEMQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAD5SWVE25GLY4SVVUK427345CNPHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQHE3DQMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AAD5SWQB6TDGI5XMEZZN67D45CNPHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQHE3DQMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Marco Antoniotti Somewhere over the Rainbow

[masinter]

just to try to wrap this up: popular Common Lisp implementations vary on their conformance to ANSII or to some earlier spec.

Given the energy going into Medley features for PSEUDOHOST and other mechanisms, and the lack of interest to make Medley ANSII Common Lisp conforming in this area, it seems unlikely that Medley can lead the raft of CL implementations.

If you want to produce portable code that will work in Medley and in other Common Lisps, you might have to fiddle with #+ #- or otherwise add Medley specific code.

If you want a list of subdirectories from a PATHNAME-DIRECTORY string with "/" delimiters inside, there seems to be the need to parse the subdirectories string.

The interaction with the o.s. and file systems and the hope of getting XNS Filing and PUP FTP and other network components seems like it will also add some requirements.

I made a mistake in attaching the PATHNAME-SUBDIRECTORY-LIST X3J13 discussion -- will move tht into an attachment, and then closing this discussion

[MattHeffron]

If you want to produce portable code that will work in Medley and in other Common Lisps, you might have to fiddle with #+ #- or otherwise add Medley specific code.

What I did long ago to have code that was specific to "Gold Hills Lisp (IBM PC)" and/or "Xerox (Interlisp)", was to write macros that would expand to the designated code based on *FEATURES*:

(DEFMACRO SELECT-SYSTEM (&REST CLAUSES)
   (DOLIST (CL CLAUSES)
       (WHEN (MEMBER (CAR CL)
                    *FEATURES* :TEST #'SAMEPNAMEP)
           (RETURN (IF (CDDR CL)
                       (CONS 'PROGN (CDR CL))
                       (CADR CL))))))

(DEFMACRO IF-GCLISP (&REST CLAUSES)
   `(SELECT-SYSTEM (:GCLISP ,@CLAUSES)))

(DEFMACRO IF-XEROX (&REST CLAUSES)
   `(SELECT-SYSTEM (:XEROX ,@CLAUSES)))

(DEFUN SAMEPNAMEP (S1 S2)
   (STRING= (SYMBOL-NAME S1)
          (SYMBOL-NAME S2)))

So I could do things like (trivial example):

(CL:DEFCONSTANT CL:MOST-NEGATIVE-SINGLE-FLOAT (MP:SELECT-SYSTEM (:GCLISP -1.0E+30)
                                                     (:XEROX -3.4028235E+38)) )


(CL:DEFCONSTANT CL:MOST-POSITIVE-SINGLE-FLOAT (MP:SELECT-SYSTEM (:GCLISP 1.0E+30)
                                                     (:XEROX 3.4028235E+38)) )

This has the advantage that these forms persist in the code and are editable in SEdit.

[marcoxa]

Hi.

Well, practically ALL Common Lisp implementations are there with ANSI, apart from some minor annoyances.

Having said that, my question stands. I do not mind creating a layer on top of the main packages and I understand that I will want to do some string parsing. One problem is that I do not know how to get the the path string out of a IL:DIRECTORY-COMPONENT. Once I have that, I can do the obvious stuff.

Marco

[marcoxa]

Yep. Silly me. directory-namestring does return the necessary string. And yet: how do you get the path from a IL:DIRECTORY-COMPONENT?

[nbriggs]

where did you get the IL:DIRECTORY-COMPONENT from?

[nbriggs]

You can get the path from an IL:DIRECTORY-COMPONENT (which is defined by a defstruct ...) with (IL:%DIRECTORY-COMPONENT-PATH ...) (likewise for the TYPE field)

(CL:DEFSTRUCT (DIRECTORY-COMPONENT (:CONC-NAME %%DIRECTORY-COMPONENT-)
                     (:PRINT-FUNCTION %%PRINT-DIRECTORY-COMPONENT)
                     (:CONSTRUCTOR %%MAKE-DIRECTORY-COMPONENT)
                     (:PREDICATE %%DIRECTORY-COMPONENT-P))
       TYPE PATH)

[nbriggs]

Watch out for whether you're typing at an XCL exec or Interlisp -- % vs %% --
This is an XCL exec:

23> (setq adc (IL:%MAKE-DIRECTORY-COMPONENT :TYPE :ABSOLUTE :PATH "a/b/c/"))
<a/b/c/>
24> (IL:%DIRECTORY-COMPONENT-PATH adc)
"a/b/c/"
25> (IL:%DIRECTORY-COMPONENT-TYPE adc)
:ABSOLUTE
26> (DRIBBLE)

[marcoxa]

Ok. Thanks. That makes sense.

I got the IL:DIRECTORY-COMPONENT from the following (in an XCL Exec)

42> (type-of (pathname-directory (pathname "Foo>Bar>Baz>")))
IL:DIRECTORY-COMPONENT

Everything makes sense.