Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!asuvax!ncar!midway!tank!stephen From: stephen@estragon.uchicago.edu (Stephen P Spackman) Newsgroups: comp.lang.lisp Subject: Re: Lisp shells for Unix (was: Extensible languages....) Message-ID: Date: 3 Sep 90 19:25:09 GMT References: <13198@hydra.gatech.EDU> Sender: news@midway.uchicago.edu (News Administrator) Organization: University of Chicago CILS Lines: 74 In-Reply-To: yukngo@obelix.gaul.csd.uwo.ca's message of 30 Aug 90 15:58:43 GMT Disclaimer: I'm approaching this as a DESIGN question, not an implementation question. You'll probably find my comments impractical if you're working with an extant system. In article yukngo@obelix.gaul.csd.uwo.ca (Cheung Yukngo) writes: I don't think I should bore you with all the problems I encountered. Here is a few more interesting ones (in my opinion): 1. How should pipes be specified? (pipe (cat prog.c) (egrep "here") (> "matches")) ? Think how the lisp interpreter should execute this thing. After you evaluate the arguments, then you do the pipe? Don't evaluate the arguments, and let each builtin function worries about the evaluation of the arguments (like is done in ELI)? How to mix outputs from, say 'car' and output from 'cat'? What about: pipe is a lazy string. (persistent-setq matches ((egrep "here") (cat prog.c))) [or, to use my fave abbrev.tchnq:] (pq matches/(egrep "here")/cat prog.c) 2. What exactly are the programs in your search PATH? Are they in the same class as 'car' and 'cdr'? Should we have: (cat "a.c") or (! 'cat "a.c") ? Should the PATH variable be continued? What about: we integrate this with the packages concept. A directory is a sort of package thing. 3. What status should be given to the output of a program? Is it a return value? Part of a return value? Side effects and nothing else? Sounds like we need to generalise multiple return values so that we can pick them out by name, maybe; or so that the function class gets to specify what happens if you don't catch all of them (like stdout and stderr get merged and status gets discarded) and what happens if you do (exit code is arg0, stdout is arg1, stderr is arg2, ...) separately. 4. With the use of lisp, the traditional one line command buffer for executing commands can be discarded (since most lisp program is not going to be one line or should be typed on the same line). What should replace it? A screen for issuing commands and one screen for executing them? One window for the commands and one window for the output, in a window system? Think about doing terminal handling and command editing as in tcsh or bash. Seems like we need a full editor. It should be PART OF an editor. System commands can be editor commands (like Gnu emacs, but with lisp, the shell, and the editor all merged). I want an output window at the top, an input window (where the cursor goes while completing long commands) at the bottom, and two PANES in the bottom window, one for past and one for future. (-: But then why am I describing undo-support features for Unix? :-). There are a lot of good things to say about a shell based in Lisp. I like the idea. The problems are interesting and challenging. Unfortunately, I have not met a single graduate student here that was interested enough to actually tried the shell. Pretty tough to tell them that parentheses are good for them :-) Have you tried telling them that parentheses are BAD for them, that they aren't intellignet enough to be allowed to use the system, that they'll probably break something and that the work is classified? :-) :-) :-):-) :-) :-):-) :-) :-):-) :-) :-):-) :-) :-):-) :-) :-):-) stephen p spackman stephen@estragon.uchicago.edu 312.702.3982