As far as I can see, each of the Perl and Python vendors have chosen a
  different strategy for their operating-system interface.  That there is
  only one vendor of each language makes it appear that all the vendors
  agree, but it is equally trivially true that all vendors disagree.  Or, in
  Common Lisp terms, (= x) and (/= x) both yield true.  So in this regard,
  what is better for Perl and Python is that there is one implementation of
  each (albeit ported), not that they all agree on anything.  I think having
  only one implementation of Common Lisp would be a dramatic setback, even
  with the clear benefits that derive from it.

| Right, so why not have a package, which is standard, but only available
| on a subset of systems you support (the POSIX ones).

  That would be good.  An abstraction of the operating system services and
  objects into Common Lisp would be fantastically welcome, precisely
  because it is so goddamn hard to do.

| Right now your Common Lisp code has lots of conditionals to handle
| implementation differences, so that's obviously not a problem.

  The problem is that there is no /one/ way to make the abstraction that
  people can agree on it.  Let us face the fact squarely: Common Lisp is
  very similar to Unix in many ways, but for that reason is different in
  ways that are hard to reconcile.  Where Common Lisp functions accept
  discrete values as input and return discrete values to the top-level,
  Unix programs read a stream of input and produce a stream of output.
  Where Common Lisp functions accept arguments of diverse types that are
  read by the standard reader before the function is called, Unix programs
  receive strings that are merely tokens of the input and have to interpret
  them itself.  Where Common Lisp functions receive keyword arguments with
  values, Unix programs accept options as special strings.  Where Common
  Lisp functions may receive nested lists of values, Unix programs receive
  a single list as arguments or parse the input stream.  Where Common Lisp
  offers special variables with globally visible changes, Unix programs
  receive environment variables that are only inherited in the process tree.
  Where Common Lisp functions resolve relative pathnames with respect to a
  special variable, Unix programs resolve them with respect to a process's
  current working directory.  Where Common Lisp functions run in the same
  memory image and can share data effortlessly, Unix programs must make
  special provisions for sharing memory.  Where Common Lisp functions can
  effortlessly use network streams and remote procedure calls, Unix programs
  have to make special provisions for both.  Where Common Lisp functions
  can call on the system parser to process input from files, Unix programs
  have to roll their own parsers for configuration files and other control
  languages.  Where Common Lisp functions all live in the image and are
  reachable by packages and symbols, Unix programs live on disk and are
  reachable by path and filename.  The conceptual similarity should be
  quite obvious all through this list because the same functionality is
  needed, but the implementation strategy is so different that it may seem
  that these are different things that can live side-by-side.  I think they
  cannot.  A certain "mapping" of the concepts between implementations need
  to take place that is far from trivial, and which probably (and evidently)
  differs from occasion to occasion.

| The improvement I'm proposing is simply that you will have standard names
| for, and access to, things that exist on 90% of the computers (99% of the
| users!) where Common Lisp does run, so you have an easier time and fewer
| implementation specific conditionals.

  But this is the same problem that faces the foreign function interfaces.
  The same things exist on both ends, but the connection between them has
  to differ because of other inherent differences.

| Perl and Python and other languages do that, but hey, you're the expert.
| If it's not worth it, then don't bother.

  I think the case is rather different than you expect.  It is not the job
  of making a standard interface that is so daunting, it is maintaining it
  across the product of all Common Lisp implementations and all POSIX
  systems.  This is rather more work than implementing it only across the
  various operating systems.  Making one POSIX package for Perl means
  making a dozen for Common Lisp, and coordinating them is a managerial
  task that is really hard to accomplish satisfactorily.

  What I actually admire in Perl is its ability to provide a very successful
  abstracttion of the horrible mess that is collectively called Unix.

--
Erik Naggum, Oslo, Norway