''Many people have proposed implementations of full lambda calculus. This permits higher level functions, i.e. functions of functions of functions etc., but allows only manipulations based on composition and lambda conversions, not general manipulations of the symbolic form of functions. ...'' : [https://web.archive.org/web/20130319041554/http://www-formal.stanford.edu/jmc/lisp20th/node5.html#SECTION00050000000000000000%|%Mysteries and other Matters], John McCarthy (father of Lisp) '''[http://www.explainxkcd.com/wiki/index.php/224:_Lisp%|%Lisp]''', short for '''LIS'''t '''P'''rocessing, is a family of [functional programming%|%functional] programming languages first specified in 1958. A modern dialect is [Scheme]--although that identification is about as incendiary in some circles as the observation that political, not linguistic, markers separate Serbia from Croatia. ** Blurbs ** ''This is one of the great advantages of Lisp-like languages: They have very few ways of forming compound expressions, and almost no syntactic structure. All of the formal properties can be covered in an hour, like the rules of chess. After a short time we forget about syntactic details of the language (because there are none) and get on with the real issues -- figuring out what we want to compute, how we will decompose problems into manageable parts, and how we will work on the parts.'' : Abelson, Harold, and Gerald Jay Sussman, [BOOK Structure and Interpretation of Computer Programs%|%Structure and Interpretation of Computer Programs], New York: The MIT Press, 1985, p. xvi ''I guarantee you there isn't one single Lisp programmer out there who uses exclusively Lisp. Instead we spend our time hacking around its inadequacies, often in other languages.'' : [http://steve-yegge.blogspot.com/%|%Steve Yegge], [http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html%|%Lisp is Not an Acceptable Lisp], 2006-04-14 ** See Also ** [Tcl and Lisp]: [Advantages of Tcl over Lisp]: [Playing Lisp]: [SEXP]: [backquote]: [Scheme]: a minimalist dialect of Lisp [Arc]: another dialect of Lisp [Lispy]: parsing S-EXP to Tcl ** Documentation ** [http://www.paulgraham.com/onlisptext.html%|%On Lisp], a book by Paul Graham: [http://www.norvig.com/paip.html%|%Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp], a book by Morgan Kaufmann, 1992: [http://www.gigamonkeys.com/book/%|%Practical Common Lisp], a book by Peter Seibel: ** Lisps ** [newLisp]: exploring how much Lisp can be improved before it becomes Tcl ;) ** Resources ** [http://www.alu.org%|%Association of Lisp Users]: maintains a [http://wiki.alu.org/%|%wiki] and [http://www.alu.org/alu/conf-all%|%runs conferences] [https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/0.html%|%CMU Artificial Intelligence Repository]: established by Mark Kantrowitz in 1993 [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html%|%Common Lisp the Language], 2nd Edition, by [Guy Steele%|%Guy L. Steele]: available online [http://www.flownet.com/gat/papers/lisp-java.pdf%|%Lisp as an Alternative to Java] (alternates: [https://web.archive.org/web/20070205105433/http://www.flownet.com/gat/papers/lisp-java.pdf]), Erann Gat, Intelligence, Winter 2000: a response to [An empirical comparison of C, C++, Java, Perl, Python, Ress, and Tcl, by Lutz Prechelt, 2000-03-10]. [http://developers.slashdot.org/story/01/09/08/0113203/lisp-as-an-alternative-to-java%|%slashdotted] on 2001-09-08 [http://www.norvig.com/java-lisp.html%|%Lisp as an Alternative to Java], Peter Norvig, 2000: a response to [An empirical comparison of C, C++, Java, Perl, Python, Ress, and Tcl, by Lutz Prechelt, 2000-03-10] [http://groups.google.com/d/msg/comp.lang.lisp/tp6mMbM9NnE/NeJA5Y3xZpAJ%|%ANNOUNCE: Lisp Without Parentheses Project (Lispin) Site Open], 2006-12-02: Ranier Josweg enumerates some of the significant differentiating characteristics of Lisp]: [http://readable.sourceforge.net/%|%Redable Lisp S-expressions]: a project that proposes a set of abbreviations that can be added to most Lisp readers, allowing a form of lisp that eschews parentheses, adds infix notation, and adds c-style function call notation. ** Description ** In Lisp, a script is a sequence of objects. composed of lists, which are represented as [SEXP%|%S-expressions]. Lisp converts each item in an S-expression into objects, interprets the first first object, which must be a symbol, as the name of a function, and evaluates the function. An item enclosed in double quotes is interpreted as a string. One of the key difference between Tcl and Lisp is that whereas Tcl automatically executes each command in a script, Lisp not only automatically evaluates each list in the script as a function, but '''also automatically evaluates as a function each argument that is itself a list'''. In contrast, Tcl interprets each argument as a `[word]`, and only performs additional evaluation as explicitly directed via `[dodekalogue%|%command or variable substitution]` syntax. Another key difference is that the Lisp reader, which ingests the Lisp script from an I/O source, can be programmed to to respond to arbitrary character sequences in the script. This gives the Lisp reader the ability process any text, '''even if it isn't Lisp'''. This is not part of the language design, per-se. Lisp just happens to include a general-purpose programmable lexer/parser. This facility could also be added to Tcl without necessitating any change to the language specification. Yet another key difference is that Lisp can be programmed to dispatch certain lists to a function instead of evaluating. The result is then interpolated verbatim into the script in place of the list, and Lisp continues to read the script starting at the beginning of the newly-interprolated section. This is known as '''macro expansion'''. Tcl may in the future also provide this feature. In some ways, Lisp and Tcl are the inverse of each other. The character `'` tells Lisp not to evaluate a list or intepret a token as a variable, whereas `[[` tells Tcl to evaluate a script, and `$` tells Tcl to perform a [dodekalogue%|%variable substitution]. In [http://www.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf%|%Fexprs as the basis of Lisp function application], 2010, [http://web.cs.wpi.edu/~jshutt/%|%John Shutt], describes an inverted Lisp that performs selective evaluation instead of selective suppression, so maybe Lisp is coming around to the Tcl way! Lisp's decision to do so much implicit evaluation can lead to some additional syntax when one wants to suppress the evaluation: ======none (list 'this 'is 'some 'data (list 'containing 'a 'sublist (list 'and 'another 'sublist))) ====== Therefore, the Lisp reader provides some sugar in the form of the character `'`, which indicates that automatic evaluation should be disabled for the object and its descendants. This suppresses not just evaluation of lists as functions, but also evaluation of tokens into objects. ======none '(this is some data (containing a sublist (and "another" sublist))) ====== Lisp, like Tcl, imposes very little absolute syntactic structure. In both languages, the basic functional units are [homoiconic%|%written in the representation] of the [list] data structure of the language. Lisp defers to its readers for additional syntactic interpretation, and Tcl defers to its commands. Tcl is the more pure list processor than in the sense that while a Lisp script can be parsed into a Lisp list, A Tcl script already ''is'' a Tcl [list]. A List is also known as a '''generalized array''', meaning an array that may contain any Lisp object, including other lists. A string is a '''specialized array''', meaning that every object in the array is restricted to a certain type. Lisp lives in a world of objects. Tcl lives in a world of words. Lisp has its reader to bootstrap into its world. Tcl expects the world it encounters to be properly formed. If one counts the default reader macros, a Lisp like Common Lisp has considerably more syntax than Tcl, primarily in order to support syntactical representation of different types such as "object", "string", and "number", but also to counteract some of the typical behaviour of [Lisp] such as automatic translation of tokens into upper-case, and automatic evaluation of lists. [EIAS%|%EIAS]` is largely responsible for Tcl's smaller syntax footprint in comparison with Lisp. One key visual difference, between Lisp and Tcl is that in a Tcl script, newlines between list items delimit commands. Whithout that feature, Tcl would look more like lisp: ====== #! /bin/env tclsh #what Tcl would look like if newlines and semicolons didn't delimit commands [set a {one two three four five}] [proc swap {listname idx1 idx2} { [upvar $listname list] [set tmp [lindex $list $idx1]] [set list [lreplace $list $idx1 $idx1 [lindex $list $idx2]]] [set list [lreplace $list $idx2 $idx2 $tmp]] }] [puts [swap a 1 3]] ====== How close is the correspondence with Tcl? [[ ... ]] maps closely to ( ... ) { ... } seems to be '( ... ) The difference (apart from `[expr]`, of course) is more in how words are grouped - in Lisp they form a list of tokens, not a string. So manipulating expressions "as text" is done by manipulating tokens in macros. And I'm at a bit of a loss to explain `$`... `Foo $bar baz` corresponds to ====== `(Foo ,bar baz) ====== [RS]: See (and maybe add to) [Tcl in comparison] ---- There have been a few "dual-language" ties between Tcl and Lisp, including several exploitations of [Tk] as a [GUI] for one or another Lisp variant. Ltk [http://www.peter-herth.de/ltk/], in particular, is a Tk binding for Common Lisp. ** Discussion ** RS: It seems to me that Lisp will probably be superseded for many purposes by a language that does to Lisp what Lisp does to machine language. Namely it will be a higher level language than Lisp that, like Lisp and machine language, can refer to its own programs." Does Tcl fit that description? I think so! As (names of) functions are just strings, they can be manipulated at every level, and both names and bodies can be manipulated... [MSW]: I strongly disagree! Tcl is NOT higher level than lisp, while lisp is "a bit" higher level than machine language :). It, in some areas, comes near Lisp because it's conceptually small, functional and list-based. Simply lacking the ability of using the language itself to easily compile itself into itself (Yes I know you can write string-procs and evaluate that, but it's super-ugly)... [RS]: Yet I guess you haven't programmed Lisp (yet, or for ages), else you wouldn't get such strange ideas :) [MSW] continues: I also think we shouldn't, with all [Tcl Advocacy] active, try to say, "Yeah, Tcl can be Lisp if you want", or "Tcl can be XXX if you want" because that's just ridiculous. If we don't have a notion of identity, how can we bring Tcl forward ? "Oh wait, Tcl. Isn't that just another Lisp dialect with less uniform syntax ?". Or, "Yeah, [C] can be lisp, too". It's the same error as the [Perl] folks made, when the claimed big-mouthedly, [Perl] is more portable than [C] (ever ported socket stuff unix <-> windows ?), higher level (how ever did they come to that conclusion when it's not about syntax-sugared operations ?) and a superset of both [sed] and [awk] (..and done so badly you want awk & sed back '''immediately'''). Instead we should be concentrating on '''Tcl''' itself ... So please let's stop disparaging any language coming along just to bring Tcl forward. [RS], you're doing a good job with your snippets on the wiki, and the wiki community in general, but Tcl fitting that description ? Come on ... [RS] replies: It may have been a bit exaggerated. But if you consider a [https://en.wikipedia.org/wiki/Job_Control_Language%|%JCL] [shell] a higher level language than Lisp, because it can glue together Lisp apps and other services, just by passing strings around? I intuitively based my theory on the fact that Tcl is based on Lisp, C, and shells... and "[everything is a string]" gives me freedoms that I would not have dreamt of when I was working as Lisp programmer (but that was 9 years ago, I admit). [TV]: My at least 5 cents about the Lisp stuff is because I like the Lisp father (see above) remark. I too used lisp, I guess 15 years ago, both on the bbc electron (which was good fun, and a good example of what one can do with 64 KiloByte core memory when programmed right) and Cambridge Lisp on the Atari 68000 machines, which I ''borrowed'' a little while from the store I bought the computer (just long enough to put the docu over the xerox machine), less fun but quite powerful, with the atari classic Mac redone graphical interface linked into it. What Lisp does to machine language is probably not straightforwardly understood for those not used to making their own assembler... I guess what he means is that it takes on a certain idea (list processing) and makes that concept into an interpreted, machine independent language with functional (and lambda) programming. As I stated elsewhere on this wiki I think, at some point the 'connection machine' was made, long ago, which took the list processing onto the hardware machine level, and took at least a step further with the [Xector] concept (as I remember an associative vector, mapped on an Order(kilo) parallel machine). [MSW]: To me, Tcl is "another kind of lisp", ranging a bit lower in highlevelness than Lisp (continuations, closures, functional language..), but what I meant is, Tcl is Tcl. Tcl is fine, but Tcl is Tcl. Everything being a string (nearly :) also means you're into [Quoting Hell] when writing functions which write functions which rewrite themselves on use e.g., or building aggregate functions. It's just too ugly to use for that kind of stuff ('''imo'''!), while Lisp macros have a wonderful, sane and clean feeling, and you still use Lisp to write the resulting expressions. (Just as you would use Tcl to write the string, true, but nothing being evaluated, and triggering evaluation with ''',''' is much cleaner than fighting with \n's being ''not'' evaluated if you use {}s, or $[] .. being evaluated if you use "s when you want something to write something for you. Example: ======none % set str [format {a\nb\n%s\n} banzai] % puts $str => "a\nb\nbanzai\n" % set str "a\nb\nbanzai\n" % puts $str => a b banzai % ====== Gluing things together doesn't appear as being "higher level" to me either. It's just a pattern of usage. Hope I didn't sound too offending btw :) [TV]: I think the idea of Lisp and Tcl being different shouldn't be played on syntax issues where certain braces and quotes could be replaced by a Lisp eval or subst idea, because I guess it is not untrue those things can make you lose track, but if you'd do the same in lisp, you'd immediately get into braces hell, and maybe worse, and the main event loop of most official lisps is a singular event loop which is also called 'eval', which is not so different at all. The extras in lisp also cost you some link to UI elements, files, and especially sockets, and then the games of interpreted concept complete-like are quite similar, even the functional (de-) composition hierarchy being quite comparable mostly. When it is about aesthetics, you could shell script lisp applications together, and be in another quoting (and debugging) game. Unless braces are nicer than quotes. In that sense Lisp is (somewhat) more uniform by nature. <> Language | Tcl and other languages