Re: Naive DEFSYSTEM replacement

I hope my earlier email this morning helps answer these questions. In 
brief, it's not simply that CL's filesystem interface contains support 
for non-POSIX, non-Windows filesystems. It's that in doing so, it 
avoided making commitments to how to map onto POSIX filesystems, so that 
*there is no single, consistent way to map CL pathnames onto a POSIX 
filesystem*.  **This is intentional:**

> Some file systems naturally use a structural model for their 
> filenames, while others do not. Within the Common Lisp pathname model, 
> all filenames are seen as having a particular structure, even if that 
> structure is not reflected in the underlying file system. **The nature 
> of the mapping between structure imposed by pathnames and the 
> structure, if any, that is used by the underlying file system is 
> implementation-defined.** [CL Hyperspec, 19.1.2, Emphasis added]

This should not be surprising:

POSIX standard, 1988.
Windows file systems: FAT (1977), HPFS (1988), NTFS	(1993)

Common Lisp, the Language, 1984
ANSI CL standard, 1994

H/T Wikipedia for these.

CL was substantially complete before POSIX took over the world, and 
before Windows was as dominant as it finally became (and indeed, it's my 
impression that Windows is *still* underrepresented in the CL community, 
compared to Unix variants -- including MacOS -- but that's a subjective 
impression).

Anyway, for better or worse, the CL specs *purposely* under-determined 
the mapping from pathnames to filenames, and there has been no 
systematic attempt to overcome this.  CL maintainers don't talk to each 
other that much and anyway, no one has the resources to create a new 
standard nor do the maintainers have the resources to comply.  UIOP 
fills the gap.

On 28 Jul 2025, at 2:21, Yuri Davidovsky (as work at disclosure dot ie) 
wrote:

>> On 28 Jul 2025, at 02:52, Robert Goldman (as rpgoldman at sift dot 
>> net) <[email protected]> wrote:
>>
>> I should also mention that a LOT of the code in ASDF/UIOP is for 
>> portability. The CL spec, because it was written in a time when there 
>> was more variation in operating systems and file systems than there 
>> is today. So it is too weak to allow writing a system like ASDF in 
>> pure CL: it requires engaging with implementation-specific code to do 
>> anything much with the file system, and ASDF has to do A LOT with the 
>> file system.
>
> I was actually wondering about the environment specific pathways and 
> why there is still much cruft related to it in CL (the same asdf, 
> e.g.) although the common sense would suggest that it was mostly 
> operating system specific, and not implementation specific. I 
> understand that asdf started in the early 2000s (as per one of the 
> previous emails) which is respectably old but I have a hunch that even 
> at that date the main systems you would have to deal with would be  
> windows, linux and macos (with the latter two being unix systems with 
> similar pathname handling as that was the time when apple released 
> darwin (which is based on FreeBSD, as I am aware)). Anything other 
> from the list of three would be also very likely standard unix 
> operating systems, so how much did asdf really have to deal with funky 
> pathname formats?
>
> I would imagine nowadays you virtually won’t be getting anything 
> outside of the list of three, or maybe also a BSD system, which is 
> still a unix with standard pathname handling.
>
> As older systems were getting decommissioned, most likely the code (if 
> it was still needed) was updated to deal with new pathname formats on 
> the new system (just for sanity if anything), and if it wasn’t then 
> it likely wasn’t needed altogether anymore and trying to package it 
> the way it was written may be not worth the effort. Whoever owned the 
> code should’ve updated the pathname handling themselves for the new 
> OS, if only not to propagate the cruft further into the ecosystem.
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html