Xref: utzoo comp.lang.misc:8022 comp.lang.lisp:5058 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!markf From: markf@zurich.ai.mit.edu (Mark Friedman) Newsgroups: comp.lang.misc,comp.lang.lisp Subject: Lisp and "Little Languages". Message-ID: Date: 17 Jun 91 15:52:55 GMT References: <16867@helios.TAMU.EDU> <1991Jun05.013632.3198@convex.com> <1991Jun05.220157.13416@convex.com> <541@smds.UUCP> <552@smds.UUCP> <2154@sheol.UUCP> Sender: news@ai.mit.edu Reply-To: markf@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 59 In-reply-to: throopw@sheol.UUCP's message of 16 Jun 91 20:16:18 GMT In article <2154@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes: A thought that occurs to me is that the rapid adoption of perl in the Unix community is a back-door defection to a philosophy that Lisp folks have been preaching for years. In perl, one is partly abandoning the the notion of small, stand-alone tools that do one thing well, and instead adopting the monolithic everything-in-one-language approach that Lisp has always had. You know. "Swiss army chainsaw." Perl simply makes this palatable to the Unix community by leaving out some of the parenthesis and including a baroque syntax and idiosyncratic semantics. :-) Although I understand why many people think of Lisp (esp. Common Lisp) as a "Swiss army chainsaw", Lisp folks do not, on the whole, preach the philosophy that you are crediting them with. On the contrary, Lisp folks have very much espoused the small, do-one-thing-well approach. A well designed, well programmed Lisp procedure does one thing well. This, of course, is simply good modular programming. The "stand-alone" part is where Lisp has sort of failed so far, unless you consider that Lisp procedures stand alone in the Lisp environment. As an aside, I also find it interesting that "everybody" seems to have implemented or be implementing a tiny language or two, even if they later repent. I don't know if that's good, bad, or indifferent, but it seems to be so. This is also a philosophy preached by Lisp folks for years. Large programs are considered as the creation of application specific languages. I think that it is good. Finally, I note that I'm familiar with at least one alternative to the "brutal stripping" of syntax to allow the "outer interpreter" (eg: the shell) to smoothly encapsulate several "inner interpreters" (eg: commands with mini-languages in their arguments, like expr, grep, and so on and on). It is, however, somewhat trickier. Instead of giving symbols no interpretation at all, you can give them *lexical* significance, but no *semantic* significance. You can get away with this because the lexical significance of characters is pretty standard across languages. For example, () always match, and so on. One also has to have a regular and predictable quote convention to deal with the few leftover conflicts, sigh. But one almost always has to have some moral equavilent of this, even in "brutally stripped" syntaxes. Lisp is nice in this regard because you can leverage on the Lisp reader which matches the parentheses, handles the quoting, etc. You can also utilize the Lisp macro facility which is a standard and powerful machanism for language extension and creation. -Mark -- Mark Friedman MIT Artificial Intelligence Lab 545 Technology Sq. Cambridge, Ma. 02139 markf@zurich.ai.mit.edu