> Look at "make-pathname" [1], for example. It was made as general as possible as a compromise between all the different filesystem path representations used at the time. On modern systems, several of the parameters, like the host, device, and version don't really make sense any more, but they're still there for backwards compatibility.
As it happens, I'm at the beginning of writing a CL for a very constrained, very weird little environment (hope to have a Show HN about it in a few months to a year), and the host and device parameters are extremely useful to me.
They're keywords; you needn't use them if you don't want them.
> My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard.
Which is sad, since a new standard (say, a CL-2015 package…) would be able to build on top of much of what is really good about CL.
> As it happens, I'm at the beginning of writing a CL for a very constrained, very weird little environment (hope to have a Show HN about it in a few months to a year), and the host and device parameters are extremely useful to me.
I would love to see an example of pathnames being useful today. In my experience they're the only part of Common Lisp that is an active impediment to getting work done on a Unix system. It would be awesome if we could have a generic file naming mechanism that would also represent URIs. Unfortunately Common Lisp pathnames manage to suck at both Unix filenames and URIs.
As it happens, I'm at the beginning of writing a CL for a very constrained, very weird little environment (hope to have a Show HN about it in a few months to a year), and the host and device parameters are extremely useful to me.
They're keywords; you needn't use them if you don't want them.
> My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard.
Which is sad, since a new standard (say, a CL-2015 package…) would be able to build on top of much of what is really good about CL.