Talk:Common Lisp

From Wikipedia, the free encyclopedia

Contents

[edit] Kyoto CL

I think that the 'See Also' link to Kyoto Common Lisp is irrelevant and should be flushed. KCL is now only of historical interest since it does not conform to the ANSI standard. Its successors, among them GNU Common Lisp (GCL) are out there, but frankly I don't think that there should even be entries for them, or even perhaps for WCL which is also listed. If nobody complains in a few days then I'll remove those links. --James (Fri Mar 26 08:48:54 UTC 2004)

It is not the way of Wikipedia to discard knowledge about historically relevant software simply because it is not currently useful software. You can see this, for instance, in the number of articles we have for implementations of BASIC. The current article on Kyoto Common Lisp claims that it conforms to the ANSI standard; if this is inaccurate (it should probably at most say "purports to conform") it should certainly be corrected. But please do not delete entries for this or other software simply because nobody uses it anymore -- "historical interest" is not a reason to delete, but a capital reason to retain Wikipedia articles. --FOo 14:14, 26 Mar 2004 (UTC)
I edited the page a little bit and forgot to summarize (BTW: this was the first time I edited a wikipedia page). First, I removed the "perhaps the most" in "CMUCL is perhaps the most widely-used [...] implementation". It is a subjective opinion about something that is perhaps not even a fact (gcl and clisp are both very popular, and SBCL seems to gain popularity too). I also added two entries in the external links. --Fredokun (Mon Apr 12 10:11:01 UTC 2004)
I believe the organization of this article as it stands now is inhibiting a clear description of the topic area. For example, ANSI Common Lisp is a dialect distinct from CLTL. KCL, in my parlance, is an implementation, not a dialect. Presently it cannot be said that it either does or does not conform to CLTL or ANSI Common Lisp (or CLTL2 for that matter) because there is no recognition of those things as referentially separate entities. (There is an article on CLTL, but that is about the book, not the dialect described by the book.) It's hard to know how to fix some of the problems I see with this article without sorting this out. (And, incidentally, the Lisp article has similar issues.) -- Netsettler 07:53, 14 November 2007 (UTC)

[edit] Dynamic scoping in pre-Common Lisps

It is not true that Scheme introduced static scoping, and it is very unlikely to be true that ZetaLisp was dynamically scoped. Before Scheme, you had two behaviors; an implementation's interpreter usually used dynamically scoped variables, while its compiler used statically scoped variables. This is the case in Lisp 1.5 (I have the manual which documents that), MACLisp, and very probably ZetaLisp (though I haven't tried in this last one). Since ZetaLisp was basically MACLisp with some additions, and both have greatly contributed to the design of Common Lisp, the statement "Most of the Lisp systems whose designs contributed to Common Lisp [...] used only dynamically-scoped variables" is incorrect. I have therefore corrected the article. --Sam 01:48, 17 Feb 2005 (UTC)

Well, MACLISP documented what the implementation did, it didn't begin with a description and then try to implement it. Had it begun with a specification, I doubt anyone would have said "Let's make it do different things compiled and interpreted." Also, the lexicality it offered was not as grand as what one thinks of today as lexical scoping. Mostly all it got you was the "compiling away of the name" so it didn't confuse EVAL or collide with SPECIAL variables. Lexicality, such as it was in MACLISP, was quite impoverished. It did not extend to the offering of closures. Joel Moses, if I recall correctly, wrote a paper about this issue--something like The Function of FUNCTION in Lisp or some such. And MACLISP had a *FUNCTION operator that tried to be a feeble workaround to a subset of the problems caused by the lack of lexical closures. Zetalisp had a LET-CLOSED operator that did something even weirder. People knew there was a problem but they hadn't articulated what needed to be fixed, I think. Scheme helped the Lisp community sort that out, drawing on ideas from ALGOL and the Lambda Calculus. And CL re-integrated the Scheme ideas into the MACLISP family. -- Netsettler 07:53, 14 November 2007 (UTC)

[edit] Sentence meaning

Common Lisp automatically coerces numeric values among these types as appropriate.

What does that mean? --maru 21:34, 12 May 2005 (UTC)

You don't have to cast numbers into the appropriate type before operating on them. The result will automatically be of a type that respects the operands' precision and the result's value.
You can add an integer and a float and get the right answer: (+ 4.5 4) is the float 9.5. If you add the ratios 1/5 and 4/5, the answer is the integer 1, not a ratio. Likewise, if you add the complex numbers #C(0 -1) and #C(1 1) -- that is, − i and 1 + i -- the answer is integer 1, not a complex. --FOo 02:11, 13 May 2005 (UTC)
As a follow-up -- here's the definition of coerce from the CLHS glossary:
coerce v.t. (an object to a type) to produce an object from the given object, without modifying that object, by following some set of coercion rules that must be specifically stated for any context in which this term is used. The resulting object is necessarily of the indicated type, except when that type is a subtype of type complex; in that case, if a complex rational with an imaginary part of zero would result, the result is a rational rather than a complex---see Section 12.1.5.3 (Rule of Canonical Representation for Complex Rationals). [1]
Not sure if that helps, but there it is. --FOo 16:02, 13 May 2005 (UTC)
Your first one cleared it up, thanks. The second one... not much so. --maru 16:13, 13 May 2005 (UTC)

[edit] How do I define a function

The article contains a paragraph which tells us how to use a macro but it does not tell how to create a function.

  • You do it with defun, as explained in the Syntax section. Or you can use lambda expression as explained in the main LISP article.  Grue  18:12, 12 Jun 2005 (UTC)


[edit] CLOS

Shouldn't CLOS be mentioned somewhere on here, if only to demonstrate that Common Lisp is a multi-paradigm functional language. However, I'm not an experienced enough Lisper to make such an edit properly.

[edit] Wikibook

For anyone interested there is a Common Lisp Wikibook. So far I'm the only one who's editing it. I'd like some more collaboration...  Grue  13:56, 10 January 2006 (UTC)

[edit] Special Operators

I fixed some minor factual errors. Or, not so minor from an implementor's point of view, e.g., mine. Neither DO nor DEFUN are special operators, and conditions aren't necessarily special types. Conditions could be special types, but implementors can use defstruct or defclass much more easily. Klodolph 07:33, 17 January 2006 (UTC)

Great! It's good to have an implementor's input on this article, by the way. What implementation do you work on? --FOo 08:44, 17 January 2006 (UTC)

[edit] Confusion

I removed the following text from the "Scalar types" section because it's confused, conflating symbols as data (which are not variables) and symbols in code (which are):

Symbols in Lisp are similar to identifiers in other languages, in that they are used as variables to hold values; however, they are more general and can be used for themselves as well. Normally, when a symbol is evaluated, its value as a variable is returned. Exceptions exist: keyword symbols such as :foo evaluate to themselves, and Boolean values in Common Lisp are represented by the reserved symbols T and NIL.

Also, I don't like this "Class instances are similar to structures, but created by the object system, CLOS." Structs are as much a part of CLOS as anything else; they're just a different metaclass (structure-class rather than standard-class per default)

Tacitus Prime 11:44, 2 November 2006 (UTC)

Someone please rephrase this: "Anonymous functions are defined using the lambda special operator." Lambda is not a special operator. Tacitus Prime 11:49, 2 November 2006 (UTC)

[edit] paradigms?

This article says "imperative, functional and object-oriented", but only the latter 2 are given at Multi-paradigm_programming_language. I'm too lisp-newbie to fix it. Hope this helps, "alyosha" (talk) 18:06, 23 June 2007 (UTC)

Multi-paradigm_programming_language is wrong. CL supports all three of those.  Grue  22:00, 23 June 2007 (UTC)

[edit] explanation of let

; construction - variables existing only in 'let' block, so you can easily give any new
; values to any existing variables without changing them. Old values are restored after
; the end of the block.
(let ((a 6) (b 4))

The comment is not a good explanation. It's not that the old values are "restored", and this might be confusing to someone coming from another language. Rather, the scope of a and b is limited to this block and those bindings are not seen outside it. —The preceding unsigned comment was added by Subsolar (talk • contribs).

[edit] Information on the Standard Itself

There is none. When was ANSI Common LISP first established as a standard? What revisions has it gone through? Why do we need a standard for LISP? I think answers to these questions belong in the article. Bunnymittens 15:27, 16 November 2007 (UTC)

I concur. See my remarks above (somewhat buried in the Talk:Common_Lisp#Kyoto_CL section) about how I think the problem is structural in this document, not separating legit dialects into separate articles so that something can be said about ANSI CL separate from about CLTL, for example. If that were fixed, I'd certainly be willing to lace in some appropriate remarks about the standard's history and status. -- Netsettler (talk) 00:07, 17 November 2007 (UTC)

[edit] Generic functions

The add example is a terrible example, since string concatenation doesn't have the same algebraic properties as numeric addition. People should not be defining methods that do utterly different things. Unlike the "overloaded funtions" found in other languages, generic functions are intended for use for use where the different implementations follow the same abstract description, and this example blurs that. Couldn't we please think up an example that does something properly generic, such as a user-defined walk generic function that works like CL's mapc but works not just on lists and vectors but also arrays of any arity, and maybe even hash tables, packages, etc? If one was going to keep the add concept, it should be used to show a user-defined numeric datatype, such as, perhaps, a polar complex form, an irrational number, a symbolic name, a repeated decimal, etc. -- Netsettler (talk) 02:51, 28 January 2008 (UTC)

I agree. Ideally the example should be: short, executable, use at least one user defined class, the methods should implement a semantically related operation and it should involve more than one argument. -RJ —Preceding unsigned comment added by Joswig (talk • contribs) 15:40, 31 January 2008 (UTC)
As inappropriate as the example usage would be, it seems to communicate the language feature very clearly. Now that the 'syntax' is communicated, perhaps an additional example and explanation could show something properly generic. —Preceding unsigned comment added by Steve Meacham (talk • contribs) 18:39, 7 May 2008 (UTC)