4 ms·

I’ve never actually understood how pathnames work in CL actually.

lisper 7y ago
That makes two of us. But they aren't strings :-) (Seriously though, is it pathnames you don't understand or logical hosts? Because CL pathnames are actually pretty straightforward. Logical hosts, on the other hand, are a hot mess.)
- tester89 7y ago
  I don’t really understand how the #P”” “strings” aren’t différent from strings.
  - lisper 7y ago
    They are different types. ? (type-of "this is a string") (SIMPLE-BASE-STRING 16) ? (type-of #P"/this/is/a/pathname") PATHNAME You can't perform string operations on a pathname. ? (subseq "This is a string" 5 15) "is a strin" ? (subseq #P"/This/is/a/pathname" 5 15) > Error: The value #P"/This/is/a/pathname" is not of the expected type SEQUENCE. You can perform pathname operations on a string, but only because the string is automatically converted into a pathname first.
gumby 7y ago
They are pretty straightforward: they are just path structures rather than path names that may turn into single strings when supplied to your kernel. Or, depending on the OS maybe only part of the name is turned into a string and part determines which device or syntax applies. All of which is abstracted away by the path objects. Back in the 1970s when thins first appeared on lisp machines is was not uncommon to use remote file systems transparently, and those remote file systems could be on quite different OSes like ITS, TOPS10 or -20, VMS, one of the lisp machine file systems and even Unix (though Networking came quite late to Unix). “MC:GUMBY; FOO >” and “OZ:<GUMBY>FOO.TXT;0” were perfectly reasonable filenames. Some of those systems had file versioning built into them. So if the world likes like Unix to you some of that additional expressive power could be confusing. C++17 path support is a neutered version of Common Lisp’s.
- tester89 7y ago
  Ohh, so they’re kinda like date objects?
  - lisper 7y ago
    Exactly. A pathname in CL is a data structure. Some of its fields are strings, but others (like version) are not.

That makes two of us. But they aren't strings :-) (Seriously though, is it pathnames you don't understand or logical hosts? Because CL pathnames are actually pretty straightforward. Logical hosts, on the other hand, are a hot mess.)

tester89 7y ago
I don’t really understand how the #P”” “strings” aren’t différent from strings.
- lisper 7y ago
  They are different types. ? (type-of "this is a string") (SIMPLE-BASE-STRING 16) ? (type-of #P"/this/is/a/pathname") PATHNAME You can't perform string operations on a pathname. ? (subseq "This is a string" 5 15) "is a strin" ? (subseq #P"/This/is/a/pathname" 5 15) > Error: The value #P"/This/is/a/pathname" is not of the expected type SEQUENCE. You can perform pathname operations on a string, but only because the string is automatically converted into a pathname first.

gumby 7y ago

They are pretty straightforward: they are just path structures rather than path names that may turn into single strings when supplied to your kernel. Or, depending on the OS maybe only part of the name is turned into a string and part determines which device or syntax applies. All of which is abstracted away by the path objects. Back in the 1970s when thins first appeared on lisp machines is was not uncommon to use remote file systems transparently, and those remote file systems could be on quite different OSes like ITS, TOPS10 or -20, VMS, one of the lisp machine file systems and even Unix (though Networking came quite late to Unix). “MC:GUMBY; FOO >” and “OZ:<GUMBY>FOO.TXT;0” were perfectly reasonable filenames. Some of those systems had file versioning built into them. So if the world likes like Unix to you some of that additional expressive power could be confusing. C++17 path support is a neutered version of Common Lisp’s.

tester89 7y ago
Ohh, so they’re kinda like date objects?
- lisper 7y ago
  Exactly. A pathname in CL is a data structure. Some of its fields are strings, but others (like version) are not.