Talk:Lisp (programming language)

Function CAR in LISP program returns the first element in a list.

  (car '(a b c d))
  Returns a

Function CDR would return everything but the first element in a list.

  (cdr '(a b c d))
  returns (b c d)

There are of course many variations of this.

  (cadr '(a b c d))
  Returns b

Working from the inside out is the same as (car (cdr '(a b c d)))

I would insist to reintroduce "Lot of Insane and Stupid Parenthesis" somewhere this is a famous joke and has also its place in Wikipedia. Ericd 20:27 Apr 14, 2003 (UTC)

It is in there. Paragraph 2 of "Syntax". It's "Lots of Irritating Superfluous Parentheses", btw (sometimes also "Lots of Isolated Silly Parenthesis".) -- CYD

I propose that this page should be entitled Lisp programming language for two reasons: First, the spelling "LISP" (in capitals) does not seem to be used among current practitioners of the language. (See for instance the newsgroup comp.lang.lisp and the work of Paul Graham.) Second, this will bring it in line with the other pages of the form "Name programming language" while preserving distinction from the word for the speech impediment. --FOo 00:40 7 Jun 2003 (UTC)

I don't think we need programming language. In fact, many article has no programming language suffix. Take Fortran, C Plus Plus and so on. -- Taku 00:47 7 Jun 2003 (UTC)

Hmm. LISP is its proper name, and since it's an acronym, it seems to me more appropriate to keep it in caps. Perl, for example, is in lowercase, since it was backronymed, and is not really supposed to be in caps. COBOL remains uppercase, without the "programming language" suffix. Fortran has no suffix either. Convention seems to say leave it as is... -- Wapcaplet 00:58 7 Jun 2003 (UTC)

"LISP" is long-obsolete; look at 2nd edition Common Lisp the Language from 1990 for instance, it's always spelled "Lisp", in contrast to 1st ed., which used small caps. I'd personally prefer Lisp (programming language) because someday we might have spiffy software that filters ()-disambiguators in article headings and such, but Lisp programming language is OK too. Stan 01:12 7 Jun 2003 (UTC)

There already is such a thing: the magic piping trick. For example, typing [[spin (physics)|]] gives you spin. Unlike the names of other programming languages, Lisp has another meaning, i.e. a speech defect. Therefore, the article should be named Lisp (programming language). -- CYD

Since there is an obvious ambiguity, I have no objection to rename this to Lisp programming language. Please don't use (programming language) because that style is not used usually. -- Taku 01:53 7 Jun 2003 (UTC)

According to the convension about naming programming language, we don't put pre-diambiguation programming language. It is debatable but is an agreement that seems reached. I am not sure which one LISP or Lisp. To me LISP sounds rather antiquated but I am not sure. -- Taku 01:19 7 Jun 2003 (UTC)

To me, spelling it "LISP" reeks of either a botched transliteration from small-caps (as with "UNIX", see the jargon file) or a usage on all-caps terminals or filesystems. Bleah. I recognize the "Foo programming language" (rather than "Foo (programming language)") convention for languages whose names have another meaning (like Python, C, and Lisp, and unlike Fortran) --FOo 03:55 7 Jun 2003 (UTC)

I agree that this should be moved to "Lisp programming language". The lower case form is much more common. -- Minesweeper 17:33 7 Jun 2003 (UTC)

Which variants of Lisp have native Unicode support? --Hirzel

http://www.cliki.net/Unicode%20and%20Lisp -- Taku 02:17 12 Jun 2003 (UTC)

Thank you for the answer!

The article says:

A minimal Lisp needs just a few functions implemented in C or machine language.

   * car
   * cdr
   * cons
   * quote
   * eq
   * cond
   * a mechanism to define functions

Is there an open source C (or Pascal, Basic or whatever implementation) which shows how this is done? A lisp version is found here (use link McCarthy's original implemenation) --Hirzel 08:08 1 Jul 2003 (UTC)

Is "cond" really necessary? I think if you define "true" and "false" appropriately, you could implement cond. Also, is it possible to implement gt and lt if you only have eq?

Yes. You need some means of making a branch, or conditional statement -- either cond or if can provide this. As for eq, it is not used for arithmetical equality, but rather for determining whether two symbols are the same. Arithmetic doesn't enter into it -- this is a minimal set of operations for list and program-code manipulation, not for arithmetic. Anyhow, arithmetic can be implemented (slowly!) in terms of lists or functions, as by using a W-representation or Church integers. --FOo 15:04, 7 Aug 2003 (UTC)

Forgive my notation, but True can be defined as "\ x . x" and False as "\ x ." where "\" is lambda. Then cond would be unnecessary because True and False would take care of it. Of course, if you're using eager evaluation, this isn't quite true, because "(False foo)" will still evaluate foo (which doesn't matter if it's referentially transparent).P3d0 15:15, 7 Aug 2003 (UTC)

It wouldn't be Lisp anymore then; "cond" is the fundamental conditional construct shared by all Lisp versions. Stan 16:10, 7 Aug 2003 (UTC)

Have a little imagination. If I can get the effect of "cond" using lambda calculus, I'm sure someone smarter than me can get the syntax in a similar fashion. Lambda calculus is Turing-equivalent on its own, and doesn't need a "cond" primitive to get that way. --P3d0 11:27, 8 Aug 2003 (UTC)

This is an article on Lisp, not alternate possibilities for Lisp-like languages. The purpose of the encyclopedia is to describe things as they are, not as they could be, unless the hypothetical somehow elucidates. For instance, one could make a comment that "cond is not strictly necessary under some evaluation regimes" or some such, and in fact there is an interesting little bit of history about how these particular primitives came to be chosen. Stan 13:45, 8 Aug 2003 (UTC)

It wouldn't be Lisp since Lisp cond and if are defined as having conditional evaluation of arguments. For that matter, it should be theoretically possible to make a Lisp system solely out of NAND gates (including flip-flops for memory), but that does not mean that NAND constitutes a Lisp system. --FOo 14:03, 8 Aug 2003 (UTC)

I'm sorry, I must not understand what you mean by "minimal" then. If I can implement cond using elements that are already in the language, then I don't need cond, right? I'm almost certain I could define cond in terms of "a mechanism to define functions" (ie. lambda calculus), making it redundant in a minimal Lisp. If you really don't believe me, I'll take the time to actually do this, though I'm not a lambda calculus expert, so it will take some effort. If it's just the concept of "minimal" that we disagree on, then that may be easier to resolve. --P3d0 15:15, 8 Aug 2003 (UTC)

If you dropped any of these functions, a Lisp programmer would say "this isn't Lisp anymore", so "minimal" is the right word. It doesn't matter what lambda calculus is capable of (by that standard, car/cdr/cons aren't necessary either), because this is about Lisp the language as it is normally understood. If you want to write about some other language that looks like Lisp but has fewer primitives, publish an article about it in Dr. Dobbs and then we'll reference it here. Stan 15:31, 8 Aug 2003 (UTC)

If P3d0 can implement cond using lambda calculus, including the syntax, his objections would be valid. However, I don't see how to do that off the top of my head, and it may not be possible. -- CYD

Ok Stan, I think I see where you are coming from. Whether cond is defined by lambda calculus, or is provided as a primitive, the fact remains that it must be defined somehow in any language that claims to be Lisp. So I yield. :-)

Incidentally, CYD, do you think a Turing machine could implement an interpreter for cond, including the syntax? If so, lambda calculus can do it too, because lambda calculus is Turing-equivalent. --P3d0 03:48, 9 Aug 2003 (UTC)

My point is that it is probably syntactically impossible, since cond uses some special syntactic rules that are treated specially by the Lisp interpreter. In other words, you'd have a problem getting the input into your "Turing machine" without encountering an interpreter error. Of course, I'd be happy to agree that you were correct if you can show us how to implement cond with lambda. -- CYD

Are you talking about the fact that cond is variadic? Besides that, keeping in mind that I don't know Lisp, how's this...

(defun true (y n) (y))
(defun false(y n) (n))
(defun cond(x) x)

In other words, with the right definitions of true and false, cond is a no-op. Or, if you don't like that one, there's this:

(defun cond(x) x)(
    (ys eq ()) (n)          -- If there are no predicated expression, return the "else"
    (
        (caar ys) (cadr ys) -- If the first predicate is true, return its expression
        (cond (cdr ys) n)   -- Otherwise recurse without the first predicated expression
    )
)

This assumes eq returns either true or false as defined above. -- P3d0 15:24, 24 Aug 2003 (UTC)

What I mean is this. Suppose you attempt to define cond in the following way:

(defun cond (x) blahblahblah)

where blahblahblah stands for whatever you need to do with the argument x to get cond to work properly. However cunningly you attempt define this function, it would not be able to handle, e.g.,

(cond (misc-variable-name 1))

This is because, since cond is defined as a normal Lisp function, the Lisp interpreter attempts to evaluate (misc-variable-name 1). This is a no-op, because misc-variable-name is not the name of a function. That's why cond is called a "special form" - its syntax is handled specially by the interpreter. -- CYD

It works just fine if "true" and "false" have the definitions I gave. -- P3d0 11:20, 25 Aug 2003 (UTC)

No it doesn't. For your reference, here is Emacs' online documentation for cond:

cond is a special form.

(cond CLAUSES...)

Try each clause until one succeeds. Each clause looks like (CONDITION BODY...). CONDITION is evaluated and, if the value is non-nil, this clause succeeds: then the expressions in BODY are evaluated and the last one's value is the value of the cond-form. If no clause succeeds, cond returns nil. If a clause has one element, as in (CONDITION), CONDITION's value if non-nil is returned from the cond-form.

In particular, CONDITION need not be "true" or "false", it can be any symbol. A arbitrary symbol need not be the name of a function, in which case (CONDITION BODY...) can not be evaluated. This can be proven by experiment in a Lisp environment. (The code you provided cannot be evaluated, btw.)

This debate is getting a little long, and inappropriate for Wikipedia. Why don't you take this to comp.lang.lisp? -- CYD

True. I still think you're being a bit pedantic, and that the correction---from what I have given to a full-fledged bona fide cond written in lisp---would not be hard for a real lisp programmer. However, since I am not a real lisp programmer, and I don't intend to become one just to settle this argument, I suppose now is the time to call it quits. -- P3d0 00:39, 27 Aug 2003 (UTC)

I am a Lisp programmer, so I'll chime in for posterity. Were cond to be removed from the above , there would be no branching construct. Consider the code: (cond ((= x 0) 0) (t (/ 1 x))). If cond were implemented as you propose, then the code (/ 1 x) would always be evaluated, even if x were 0. cond could be replaced in the above list by either if, or both and & or (which are short-circuit evaluators). But you gotta have a primitive branching branching construct, something that prevents evaluation. Also, note that the foregoing discussion about primitives did take place on comp.lang.lisp a year or so ago. -- Piquan 10:27, 11 Feb 2004 (UTC)

I'm considering adding a section listing the arguments put forth by proponents and opponents of Lisp. Would this be useful, or would it probably just spark a flamefest? -- Piquan 10:29, 11 Feb 2004 (UTC)

Such a section would be useful, and there won't be a flamefest if the section describes the arguments, and stays scrupulously clear of trying to endorse any. If I can't tell from reading it whether you personally like or hate Lisp, then the material is properly neutral. Stan 14:58, 11 Feb 2004 (UTC)

I took the small liberty of adjusting the indentation on some code examples involving if. There's a nearly standard style of indentation for Lisp given in Steele's Common Lisp the Language, and it is unfortunate that GNU Emacs's default Lisp indentation violates this (when using the common-lisp-indent-function it behaves properly. The problem is that normally both the true and false clauses of if are supposed to be indented to the same level, but in GNU Emacs it outdents the false clause two spaces. Since this is entirely irregular (and not even that common in Emacs Lisp) I've made the change to the indentation to bring it in line with what is found in most other Lisp languages like CL, Scheme, etc. James

Lisp "popularity contests"?

Latest comment: 21 years ago1 comment1 person in discussion

Does anyone know of any statistics about the number of users of different Lisps? I'd like to know such things as:

Are there more CL-ers or more Schemers?
Which Scheme is the most popular?
How many people use CL vs. how many people use the most popular Scheme?

--Ryguasu 19:02, 6 May 2004 (UTC)Reply

I've removed this section for discussion. Despite the conversation above, it really isn't clear to me what was originally meant by it, and it's been pointed out as misleading. --FOo 00:06, 8 Jul 2004 (UTC)

Minimal Lisp

A minimal Lisp needs just a few functions implemented in an underlying language (such as machine language, or C on Unix systems):

car -- given a pair, return the first element;
cdr -- given a pair, return the second element;
cons -- construct a new pair with given first and second elements;
quote -- denote an expression as literal, not to be interpreted;
eq -- compare two objects for equality, returning true or false values;
if or cond -- a single- or multiple-condition branch operation; and
some mechanism to define functions, such as Common Lisp's defun, or else lambda and Scheme's define.

All the other functions may be implemented in terms of these -- albeit not very efficiently. Actual Lisp systems implement a much larger set of functions than this.

[ Bogus misinformation above. Given only these functions, you cannot even lexically scan a parenthesized expression, never mind evaluate it and print it. You have no symbol table management, no numeric tower, no string handlnig, nothing. ]