Version 47 of Lisp

Updated 2013-11-05 06:27:29 by pooryorick

Short for LISt Processing.

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.

On Tcl:

"No question but that real lisps are more powerful than this bastard child of lisp and awk, but for what it does it does a better job than either parent. Which is all you need to ask of it."

Re: linked lists in Tcl, part II ,Peter da Silva ,1994-10-18

See Also

Tcl and LISP
Advantages of Tcl over Lisp
Playing LISP
a minimalist dialect of Lisp
another dialect of Lisp
parsing S-EXP to Tcl
Lisp as an Alternative to Java (alternates: [L1 ]) ,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. slashdotted on 2001-09-08
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
   [|%ANNOUNCE: Lisp Without Parentheses Project (Lispin) Site Open] ,2006-12-02:  Ranier Josweg enumerates some of the significant differentiating characteristics of Lisp]


On Lisp ,a book by Paul Graham
Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp ,a book by Morgan Kaufmann ,1992
Practical Common Lisp ,a book by Peter Seibel


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 [L2 ], in particular, is a Tk binding for Common Lisp.


"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. ..."

Mysteries and other Matters ,John McCarthy (father of Lisp)

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... (RS)

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 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 progressing 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:

 % set str [format {a\nb\n%s\n} banzai]
 % puts $str
 => "a\nb\nbanzai\n"
 % set str "a\nb\nbanzai\n"
 % puts $str
 => a

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'de 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 than the games of interprested concept complete-like are quite simular, 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.