Subject: Re: A portable DIRECTORY-P. Re: Here we go again. More CMUCL/ACL pathname differences.
From: Erik Naggum <erik@naggum.no>
Date: 1999/01/13
Newsgroups: comp.lang.lisp
Message-ID: <3125217976202816@naggum.no>

* cbarry@2xtreme.net (Christopher R. Barry)
| Because in practice most of the time it doesn't make a difference for
| many of the functions if their argument is logical-pathname or a
| SIMPLE-STRING of type CHARACTER that denotes a logical-pathname
| namestring (if that's even the proper terminology).

  the technical term is pathname designator.  I love designators, myself,
  but I go out of my way to read the specification and know when I'm using
  a designator and when I'm using the real object, specifically by knowing
  what types the function _really_ takes.  I think this is much easier than
  having to deal with the obvious problems resulting from confusing a type
  with the set of types of designators for that type.

| I've gotten into the bad habit of using them interchangably, but now I'm
| less assuming.

  you should be able to, most of the time, but when you ask for specific
  details about the _type_, you can no longer assume that some function
  will magically "know" that you want what it might designate to some other
  function.  "lisp:code;fun" is a string and nothing but a string.  a
  string is a pathname designator and functions that expect a pathname will
  accept a string to make your life easier.  when this designator business
  makes people's lives harder, it's time for those people to stop using
  them and go back to using the real object types and to read the spec to
  see what kind of argument types the functions they call actually take.

  I think good Common Lisp programmers implement designators to make their
  own lives easier, too, but it takes a little extra effort in the code to
  be able to handle designators, but I'd imagine that some macro or other
  would take care of these things.

| I find there are many pitfalls like this in this huge language (or small
| language with huge standard library if that's how you prefer to look at
| it).

  one man's convenience is another man's pitfall, obviously, but it's not
  something that happens by random.  you chose to ignore the specification
  and stumble ahead with whatever "works".  that's how pitfalls are made.

| >   do you expect (null "()") to return true, too?
| 
| Hmm... no. Maybe (null (read-from-string "()")) though.

  I expect you see the need to call PARSE-NAMESTRING on the string, too.

#:Erik