Subject: Re: Using Lisp to Call another program in linux? From: Erik Naggum <erik@naggum.no> Date: 11 Nov 2002 06:03:22 +0000 Newsgroups: comp.lang.lisp Message-ID: <3245983402026014@naggum.no> * Scott Schwartz | The point is, they do the best they can under the circumstances. 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 Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.