Diskussion:Lisp

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 8 Jahren von Rolfg in Abschnitt Kommentare
Zur Navigation springen Zur Suche springen
Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Lisp“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

Frage nach den Anwendungsbereichen

[Quelltext bearbeiten]

ok.. ich bin ba-student informationstechnik. ich will nur kurz loswerden, dass LISP zwar eine interessante sprache ist um einmal das funtkionale programmieren kennen zu lernen, mir bis jetzt leider keine anwendungen dazu bekannt sind die in der heutigen praxis wirklich genutzt werden. ( würde mich freuen wenn hier mal beispiele stehen würden die mit lisp effizienter sind als andere programmiernsprachen/ - formen).

siehe dazu z.B. AutoLISP --Robert Kropf 11:23, 15. Jun 2004 (CEST)

Hallo Robert, Lisp war ursprünglich so konstruiert, dass Datenstrukturen nur sequentiell durchlaufen werden (in einer einfach verketteten Liste). Damit ist, um Dich vielleicht zu überfordern, kein "Random-Access" Memory, also kein wahlfreier Zugriff auf die Daten notwendig. In der heutigen Praxis könntest Du z. B. Daten, die über DVB-T, also sequentiell, in den Decoder kommen mit einem vor vierzig Jahren geschriebenen Algorithmus immer noch bearbeiten. --Thomas Stauß (Diskussion) 09:56, 9. Aug. 2013 (CEST)Beantworten

Thomas, ich verstehe nicht, was Du mit Deinem (teilweise in belehrendem, teilweise in beleidigendem Ton geschriebenen) Statetment ausdrücken willst. Ausserdem bin ich (TheRunnerUp bzw. unter meinem früheren Account Robert Kropf) der falsche Adressat, denn die Anfrage stammt von einer anonymen IP, während von mir nur die kurz gefasste Antwort erstellt wurde. Wenn Du also sachlich etwas zum Diskussionsthema beizutragen hast, dann mach das, wenn nicht dann halte bitte den Mund (so wie Du es in den letzten zweieinhalb Jahren auch gemacht hast). (Und zu Deiner Info: ich bin kein BA-Student, und mit der Materie soweit vertraut, dass ich die Vorteile von Lisp sehr wohl erkennen kann.) -- TheRunnerUp 15:03, 12. Mär. 2010 (CET)Beantworten
Au! Thomas hat sich offensichtlich im Bezug geirrt, diesen umstand hast Du ohnehin erkannt. Deswegen ist ihm keine böse Absicht zu unterstellen. Selbst der hypothetische Fall von Absicht wäre vielleicht absurd, jedoch nicht negativ. Der von Dir als belehrend wahrgenommene Ton rührt wohl von dem Versuch her, die ursprünliche implizite Frage zu beantworten. Und falls Du Dich auf das 'überfordern' beziehst, kann es genauso gutmütig oder schlicht konsolidierend gemeint sein. Du selbst könntest mit Deiner Antwort ebenfalls als belehrend und beleidigend ('halt den Mund') interpretiert werden. In diesem Sinne ersuche ich, die vermeintlichen Verfehlungen anderer nicht als Rechtfertigung für das selbe Verhalten heranzuziehen, sondern selbst den richtigen Maßstab zu setzen. ('Aber der hat zuerst...' gilt nicht.) Allen alles Gute -- 178.165.128.4 04:08, 13. Dez. 2013 (CET)Beantworten
Hallo 178.165..., bevor Du diesen Kommentar geschrieben hast, hättest Du die Versionsgeschichte anschauen sollen: Thomas hat einige seiner Behauptungen aus seinem Beitrag gelöscht nachdem ich die Antwort auf seinen ursprünglichen Beitrag geschrieben habe. Daher fehlt einigen meiner Aussagen der Bezug. (EoD) --TheRunnerUp 12:53, 13. Dez. 2013 (CET)Beantworten

Weitere Anwendungen

  • EmacsLISP - Skriptsprache für den Editor Emacs
  • Script-Fu ist (glaube ich) ein Scheme-artiges LISP, was zum Schreiben von Gimp-Plugins genutzt werden kann. The Gimp ist eine freie Bildverarbeitungssoftware.
  • Loom ist ein LISP-basiertes Wissenrepräsentationssystem, welches unter anderem von der für ein System amerikanischen Luftwaffe zur Einsatzplanung verwendet wird (http://www.isi.edu/isd/JFACC/jfacc-loom.html )
  • Guile ist eine Scheme-Variante, die in diversen Programmen als Skriptsprache eingesetzt wird.
  • DSSSL
  • Viaweb, ein Webshop-Anwendung, wurde 1998 von Yahoo gekauft. Siehe auch en:Paul Graham.

Akademische Anwendungen: Ok, Du wolltest v.a. "praktische" Anwendungen - ich finde aber, dass gerade LISP sehr interessante theoretische Aspekte hat

  • Scheme wird oft in der Einführung in die Informatik verwendet, da die Sprache eine sehr minimale Syntax hat, der Professor muss nur die Klammerung, die arithmetischen Symbole +,-,*,/ erklären, und kann dann live mit der Programmierung loslegen, live die geschriebenen Programme durch Term-Ersetzung interpretieren, usw. Auch ein Message-Passing-System ist in wenigen Zeilen geschrieben, um Aspekte der objektorientierten Programmierung zu demonstrieren (ohne das Scheme spezielle syntaktische Elemente dafür hätte!)
  • Programmiersprachen-Vorlesungen: Es ist recht einfach, einen LISP-Interpreter in LISP zu schreiben.
  • Formaler Entwurf usw.: LISP-Programme sind formal einfach und gut beschreibbare Datenstrukturen, für die wiederum Programme geschrieben werden können, die gewisse Eigenschaften untersuchen/beweisen können (siehe z.B. hier: http://www.cs.utexas.edu/users/moore/acl2/)

--zeno 12:46, 15. Jun 2004 (CEST)

Für praktische Anwendungen (es gibt genug!) siehe http://common-lisp.net/

Hallo, vielleicht gibt es seit 2004 noch weitere relevante Anwendungsbereiche, die man dem Artikel hinzufügen könnte? --Kebap (Diskussion) 11:14, 6. Mai 2013 (CEST)Beantworten

Abschnitt über Lambda-Kalkül

[Quelltext bearbeiten]

Ich finde den Abschnitt mit dem Vergleich zum Lambdakalkühl unverständlich und schlage vor, dass er vorerst einmal hier parkiert wird. Kurt vom Walde 18:19, 24. Mai 2005 (CEST)Beantworten

Die Ungenauigkeit und der Fehler werden nicht effektiv erklärt. Ausserdem fragt sich der Leser warum denn die Lispprogrammiersprache nach 50 Jahren immer noch verwendet wird.

Unterschiede zum Lambda-Kalkül

[Quelltext bearbeiten]

Lisp implementiert den Lambda-Kalkül nur ungenau. Nach dessen Definition ist λxy.Funktionskörper äquivalent zu λx.λy.Funktionskörper, da bei einem Aufruf der Funktion mit 2 Argumenten die äußere Funktion das erste Argument und die innere Funktion das zweite Argument konsumiert. (s. Currying) Folglich sollten auch diese beiden Lisp-Ausdrücke äquivalent sein:

(lambda (x y) ...)
(lambda (x) (lambda (y) ...))

Dies ist jedoch nicht der Fall. Während (λx.λy.(x+y)) 1 2 den Wert 3 ergibt, verursacht ((lambda (x) (lambda (y) (+ x y))) 1 2) einen Fehler, da die äußere Funktion zu viele Argumente erhält und die innere Funktion das zweite Argument nicht konsumiert.

Kurt vom Walde 18:13, 31. Mai 2005 (CEST)Beantworten

Warnung

[Quelltext bearbeiten]

Aufgrund eines unten stehenden Kommentars zu #Lisp 1.Absatz habe ich LISP ohne und mit Versionsnummer und Lisp unterschieden, dann aber beim Durchgehen des Artikels gemerkt, dass insbesondere InterLISP zu dieser Regelung quer liegt. Vereinfacht habe ich damit wohl nicht, aber zumindest die Verwendungen der Buchstabenfolge für alte Sprache, implementierung und Sprachfamilie separiert. Ich bitte, meine Editiernachfolget DIES zu beachten!!!! --SonniWP2 23:46, 1. Aug. 2007 (CEST)Beantworten

[Quelltext bearbeiten]

Was soll der Link auf Axel Strube-Zettler (www.mapcar.de), ich kann da so auf Anhieb keinen Mehrwert (ausser dem netten Domainnamen erkennen. Schlage Löschung vor.

Für Weblinks gilt besonders WP:WEB#Grunds.C3.A4tzliche_Richtlinien. Wenn die nicht eingehalten werden, kann mit Hinweis auf WP:WEB JEDER diese löschen --SonniWP 12:28, 2. Aug. 2007 (CEST)Beantworten

Kategorie: LISP?

[Quelltext bearbeiten]

Wie wäre es mit einer Kategorie Programmiersprache LISP? Die Anzahl der Artikel sollte doch reichen, Pascal hat z.B. nur 13 Einträge und wenn man alle Artikel einträgt, dürfte man auf einiges kommen (im Hauptartikel stehen ja allein schon 7 Links auf bereits existierende Artikel über Lisp-Dialekte). Wenn niemand was dagegen hat, kann ich das ja mal machen. Timo "God's Boss" Reitz 14:01, 22. Feb 2006 (CET)

LiLi als Lisp Dialekt

[Quelltext bearbeiten]

bitte seid so nett, und lasst LiLi als Lisp-Dialekt in der Liste. Ich weiß, daß die Dokumentation noch sehr unvollständig ist, die In terpreter-Implementation sagen wir "leicht dilettentatisch", aber ich arbeite an beidem. Hilfe könnte ich ehrlich benötigen, und mir liegt persönlich sehr viel an dem Projekt. Wer es sich einmal anschauen möchte, dem ist meine volle Unterstützung gewiss :) Ich weiß auch, daß LiLi nicht mit Arc oder anderen, schlaueren neuen Sprachen "mithalten" kann. Aber ich interessiere mich seit mehreren Jahren sehr für Sprachentwicklung, insb. für funktionale Sprachen und habe in LiLi halt ein paar im worst-case idiotische Sprachneuerungen "eingebaut", von denen ich hoffe, dass sie zumindest Inspiration für ernstzunehmendere Projekte werden könnten. LG, martin (belowZero@gmx.info) 11:56, 23. Jul. 2006 83.129.189.44 steht hierzu in der History

Lisp, erster Absatz

[Quelltext bearbeiten]

LISP ist eine Programmiersprache, die 1959 am Massachusetts Institute of Technology (MIT) als Implementierung des Lambda-Kalküls entstand (ANSI INCITS 226-1994 (R1999), Approved American National Standard Information Technology - Programming Language - Common Lisp (formerly ANSI X3.226-1994 (R1999))).

Irgendwie ist dieser erste Absatz schon wirr.

LISP feiert nächstes Jahr den fünfzigsten Geburtstag. Demnach wäre 1958 das Geburtsjahr und nicht 1959.

<Einschub>Nach dem Vortrag McCarthys LISP—NOTES ON ITS PAST AND FUTURE—1980, wo 21 Jahre angegeben werden, hat hier jemand 59 ausgerechnet. 1980 ist aber das Erscheinungsjahr des Abdrucks. Der Vortrag wurde ein Jahr zuvor gehalten. --SonniWP 07:52, 28. Jul. 2007 (CEST)</Einschub>Beantworten

Es ist auch nicht als Implementierung des Lambda-Kalküls entstanden. LISP basierte in Teilen auf Ideen aus dem Lambda-Kalkül - es ist damals (und heute) keine Implementation des Lambda-Kalküls gewesen.

<Einschub>#Minimaler Funktionsumfang für LISP beschreibt genau den Umfang der Sprachversion LISP 1.5 vom 1963, aus der meine Implementierung in meiner Diplomarbeit praktisch abgeschrieben wurde --SonniWP 07:59, 28. Jul. 2007 (CEST)</Einschub>Beantworten

Dann steht da etwas über ANSI INCITS 226-1994 (R1999). Das ist der Standard von ANSI Common Lisp. Der hat aber mit LISP im ersten Absatz wenig zu tun. LISP ist eben diese erste Sprache, durch McCarthy erfunden. Andererseits ist LISP später eine Familie von verschiedenen Programmiersprachen - Common Lisp ist eine davon. Somit ist der Standard von ANSI CL auch nicht der Standard von LISP und hat im ersten Absatz nichts zu suchen. Scheme hat andere Standards (IEEE, R5RS, ...). ISLisp wieder einen anderen.

Für den Artikel über Lisp (!) wäre also zu unterscheiden: LISP als Erfindung von John McCarthy, die erste(n) Implementationen von LISP und Lisp als Familie von Programmiersprachen.

In den weiteren Absätzen geht das munter durcheinander. Das sieht man auch schon an LISP und Lisp. Früher schrieb man LISP. Heute schreibt man eher Lisp.

Der deutsche Artikel braucht erhebliche Überarbeitung. Der englische Artikel erscheint mir besser. Dieser Beitrag stammt von 10:18, 5. Apr. 2007 85.176.3.207

Aufgrund dieses Kommentars habe ich LISP ohne und mit Versionsnummer und Lisp unterschieden, dann aber beim Durchgehen des Artikels gemerkt, dass insbesondere InterLISP zu dieser Regelung quer liegt. Vereinfacht habe ich damit wohl nicht, aber zumindest die Verwendungen der Buchstabenfolge für alte Sprache, implementierung und Sprachfamilie separiert. Ich bitte, meine Editiernachfolget DIES zu beachten!!!! --SonniWP2 23:46, 1. Aug. 2007 (CEST)Beantworten

Lisp-Beispiel der Lambda-Funktion

[Quelltext bearbeiten]

Vielleicht fühlt sich einer der versammelten Lisp-Gurus berufen, ein Lisp-Beispiel für Lambda-Funktionen beizusteuern und damit den Artikel Lambda-Funktion (Python) in einen allgemeineren Artikel umzuwandeln (bzw. in eine Umleitung zu den Python-Beispielen ;-)? --Tobias 14:19, 2. Aug. 2007 (CEST)Beantworten

Done. Siehe Diskussionsseite dort --Kingruedi 02:02, 25. Okt. 2007 (CEST)Beantworten

LISP vs Lisp

[Quelltext bearbeiten]

Sollte man den Artikel nicht lieber in Lisp umbenennen? --Kingruedi 01:28, 25. Okt. 2007 (CEST)Beantworten


Ich denke "Lisp" wäre unkorrekt. Pascal mag geschrieben werden, wie man will, auch Modula, da es Eigennamen sind, die nicht aus irgendwelchen Abkürzungen anderer Bezeichnungen konstruiert wurden. LISP steht jedoch für LIStProcessing. LISP als "Lisp" zu schreiben hieße, dass es ein Eigennname wäre, was so nicht stimmt und käme dem gleich WYSIWYG (What You See Is What You Get) als "Wysiwyg" zu schreiben. Übrigens ist in meiner Literatur LISP immer aus Großbuchstaben zusammengesetzt. --Thomas Stauß 12:39, 25. Okt. 2007 (CEST)Beantworten

Sollte es dann nicht eher LisP heißen? ;) --Kingruedi 16:53, 25. Okt. 2007 (CEST)Beantworten
Ich fürchte, der korrekte Titel des Artikels hängt davon ab, was man mit Lisp/LISP meint. In "historischen" Dokumenten wird durchgängig die Schreibweise "LISP" verwendet. Zeitgenössische Lisp/LISP-relevante Literatur bezieht sich fast ausschließlich auf Common Lisp und verwendet auch durchgängig die Schreibweise "Lisp". Andererseits bezieht sich diese Literatur eben auch konkret auf Common Lisp und nicht auf andere historische oder zeitgenössische Mitglieder der LISP-Familie und verwendet offenbar deshalb diese Schreibweise. Das einzige nicht-Common-Lisp-spezifische Buch, das mir spontan einfällt, wäre "Lisp in Small Pieces" von Christian Queinnec, und auch hier wird soweit ich mich erinnere durchgängig die Schreibweise "Lisp" verwendet.
Weitere zeitgenössische Mitglieder der Lisp-Familie neben Common Lisp wären EuLisp[1] und ISLISP,[2] wobei für ISLISP wiederum auch die Schreibweise ISLisp gängig ist. In der Zusammenfassung des Scheme-Standards R6RS heißt es "Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language."[3] Die Emacs-Dokumentation verwendet durchgängig die Schreibweise Emacs Lisp.[4] In der Usenet-Newsgroup comp.lang.lisp scheint auch die Schreibweise "Lisp" vorzuherrschen, auch wenn über eine andere Lisp-Variante als Common Lisp diskutiert wird. Auch die Veröffentlichung "The evolution of Lisp"[5] von Guy L. Steele, Jr. und Richard P. Gabriel verwendet durchgängig die Schreibweise "Lisp", sofern nicht konkrete Sprachen ("CLISP", "SYSLISP") gemeint sind. Man sollte eventuell auch berücksichtigen, dass offenbar in vielen älteren Zeitschriftenartikeln die Namen von Programmiersprachen in Kapitälchen gesetzt waren, was dann in Reintextmedien wie E-Mails oder Forumsbeiträgen durch Großschreibung nachgeahmt wurde.
Offengestanden sehe ich aber keinen dringlichen Bedarf dafür, den Artikel umzubenennen. —Tobias Bergemann 16:11, 25. Okt. 2007 (CEST)Beantworten
In dem Sinne meinte ich die Anfrage. Heutzutage scheint die Schreibweise Lisp üblicher als LISP --Kingruedi 16:53, 25. Okt. 2007 (CEST)Beantworten
Kommt drauf an wo. Ich denke die Schreibweise "LISP" in wikipedia entspricht der John McCarthys; "LisP" ist eine Schreibweise, die damals nicht nur nicht möglich war, sondern selbst als sie möglich war erst durch Smalltalk-77 (oder 78) aus dem unschicken Bereich geholt wurde und erst mit Smalltalk-80 veröffentlicht. Trotzdem blieb es lange Zeit Smalltalk typisch und nirgendwo sonst genutzt. Ich habe mich nach Belehrungen an die Schreibweise der Wikipedia von "Common Lisp" gehalten, sehe aber auch hier die Schreibweise in den Veröffentlichungen des "Common Lisp"-Komittees als maßgebend. Ich glaube mich an "Common LISP" zu erinnern, betrachte das aber als mindestens drittrangig.

--Thomas Stauß 10:54, 26. Okt. 2007 (CEST)Beantworten

Integration von LISP und Common Lisp

[Quelltext bearbeiten]

Irgend wie bin ich nicht sonderlich zufrieden mit der Integration der beiden Artikel in der aktuellen Form. Common Lisp ist eine eigene Sprache. Ein eigener Dialekt von Lisp. Daher ist eine Implementierung von Common Lisp eben eine Common Lisp-Implementierung. Auch wenn Common Lisp an sich nur die Spezifikation einer Sprache ist. Aber das trifft ja auch auf C, C++, ADA etc. zu. Sicher ist Common Lisp aus der Idee entstanden alle Lisp-Dialekte zu vereinen. Aber es gibt eben noch Emacs Lisp, AutoLisp oä, die aktiv benutzt werden und vor allem gibt es noch Scheme und Scheme unterscheidet sich eben wesentlich von Common Lisp. Es gibt eigene unabhängige Implementierungen, eigene unabhängige Bücher, eigene unabhängige Webseiten, eigene unabhängige Community etc. Dem wird es einfach nicht gerecht, wenn wir im Lisp-Artikel so tun, als sei alles Common Lisp. --Kingruedi 21:07, 25. Okt. 2007 (CEST)Beantworten

Hallo Kingruedi, Gut, es gibt genug Implementationen von Common Lisp, so dass man unter großen Umständen davon sprechen kann, dass Common Lisp eine Programmiersparche ist. Eigentlich ist aber LISP die Programmiersprache, die in einigen Dialekten auseinanderdriftetet. Dann begann eine Gruppe von Wissenschaftlern mit der Common-isierung, die ich schon einmal wohl undeutlich als Prozess der weiteren Entwicklung von LISP beschreiben habe. Ich habe in Deinen Worten Zustimmung gelesen dafür Common Lisp als The Lisp that's common (gebräuchlich) aufzufassen und nicht komplett als Eigennamen, der aus zwei Worten besteht. Übrigens zweigt Scheme stark von Common Lisp ab, Common Lisp von LISP 1.2 (oder war'S 1.3) garnicht. Also Scheme, das muss ich echt wissen, schließlich habe ich mich da zwei Semester durchgeplagt ist echt kein Common LISP, verwendet aber die dort entwickleten Grundlagen bezüglich allen möglichen Eigenschaften, die eine Programmeirsprache haben kann und eine ähnliche Syntax. Ja nochmal: Common ist einfach ein Adjektiv vor LISP ,"Common Lisp" ist nicht ein neuer "Markenname".

Ich drücke jetzt mit unguten Gefühlen nochmal auf das "rüchgängig": Mir artet das zu sehr in einer Art "Kampf" aus. Ich möchte Dich darauf hinweisen, dass das was ich schreibe so gut wie garnicht von mir kommt, sondern ich einfach das wiederkaue, was mir unter Verbrauch hoher Steuermittel, evt. auch der aus Deinem Einkommen, vermittelt wurde. Ich habe allerdings ein wenig den Eindruck, dass ich zu unsensibel vorgegangen bin. Wie kämst Du sonst darauf, dass ich bei den Literaturangaben den Paul Graham "On Lisp" einfach übersehen hätte. Ich habe ihn absichtlich weggelassen, da er weder mit der "Common"-Spezifikationen von LISP noch mit den daraus resultierenden ANSI-Spezifikationen von LISP etwas zu tun hat. Irgenwie bin ich ein wenig betrübt über DEin Verhalten. Was ich zu Common LISP geschrieben habe ist derart primitiv, es gibt noch so viel zu ergänzen, da gibt es noch so viel zu tun. Und ich möchte Dich wirklich herzlich einladen, Deine MItarbeit über irgendwelche Sekretariatsjobs wie Schreibweisen korrigieren, im Internet noch zusätzliche Literatur mit den Buchstaben "LISP" im Titel zu finden oder textgestalterische Tätigkeiten hinaus wachsen zu lassen. Du bist mir jetzt bitte nicht böse, ja? Aber es wäre großartig, einen Mitautor in Dir zu gewinnen, einen der sich mit dem Thema Common LISP beschäftigt. Die weitere Informationsgewinnung scheint allerdings fast ausschließlich über papierne Bücher möglich sein, ich hoffe das machst Du genauso gerne wie das Recherchieren im Internet. Ja, wäre schon nett, die veröffentlichten Schriften der Common-Lisp-Tagungen mal auf den Gehalt für einen Wikipedia Artikel zu durchforsten.


Zus.: Das Produkt LISP als sozusagen eingestellt zu betrachten und es nur historisch (und wenn mal nicht historisch, dann fehlerhaft beschrieben) zu behandeln und "Common Lisp" sozusagen als neues Produkt in einem neuen Artikel zu behandeln wird der Realität nicht gerecht. Wie gesagt, " Common Lisp" ist kein neuer "Markenname", es ist Common-isiertes LISP( alle LISPs, alle zeimlich unterschiedlich, aber alle dem "nicht vollständig ausdefinierten" LISP von John McCarthy entsprechend, durch Erweiterung der "Definitionen" (der Spezifikation) "ge-commont": zu "gebräuchlichem LISP" übergeführt. --Thomas Stauß 10:44, 26. Okt. 2007 (CEST) --Thomas Stauß 10:44, 26. Okt. 2007 (CEST)Beantworten

So funktioniert die Welt dann eben doch nicht: Natürlich war der Standardisierungsprozess von Lisp in der Form gedacht, wie du ihn beschreibst. Aber man kann Geschichte nicht rückgängig machen und der Ansatz mit Common Lisp einen Deckel auf Lisp zu setzen hat nicht geklappt. Aus Common Lisp ist ein eigener Dialekt geworden. Eine eigene Sprache.
Es existieren eben andere Lisp-Dialekte, die immer noch benutzt werden (EmacsLisp, Scheme). Und Scheme ist genau wie Common Lisp ein eigener Dialekt. Wobei die Scheme Entwickler eher den Weg gegangen sind, altlasten wegzuwerfen und die Spezifikationen aufzuräumen, während die Common Lisp Leute den anderen Weg gewählt haben. Aber auch Hersteller von Implementierungen und Buchautoren benutzen Common Lisp als Begriff für eine eigene Programmiersprache. Die Formulierung kann Dialekt X und auch Common Lisp findet man durchaus bei Herstellern von Implementierungen.
Daher muss man Common Lisp als eigene Sprache behandeln, egal was das Motiv hinter der Entstehung war.

--Kingruedi 16:58, 26. Okt. 2007 (CEST)Beantworten

Um das noch mal klar zu stellen: Common Lisp ist ein eigener Dialekt! Das schreibt Steele so in CLTL. Das wird anscheinend auch überall woanders so gesehen. Wie man an der Verwendung des Begriffs sieht. Die Stellen die du aus dem Common Lisp-Artikel hierher kopiert hast, gehört nicht hier her, da sie teilweise Common Lisp spezifische Dinge beschreiben. Zum Beispiel die Daten Typen oder die Variablenbindung. Alle Lisp-Dialekte bis auch Common Lisp und Scheme haben zB kein lexikalisches Scoping. Auch die Datentypen lassen sich so nicht verallgemeinern. Implementierungen etc. sind wohl eindeutig Common Lisp spezifisch. Zusammenfassen lässt sich sagen, dass die Änderungen sehr schadhaft und falsch waren. Ich werde die nächsten Tage nutzen, um sie wieder sinnvoll rückgängig zu machen! --Kingruedi 23:39, 27. Okt. 2007 (CEST)Beantworten

Interpreter/Compilersprache

[Quelltext bearbeiten]

Ich kenne mich in lisp überhaupt nicht aus, kann da jemand am anfang hinschreiben, um was es sich handelt? (nicht signierter Beitrag von 85.124.169.211 (Diskussion) )

Das ist nicht festgelegt. Im Artikel steht: Programme in Lisp können interpretiert oder von einem Compiler in effizienten Code übersetzt werden.
Ich habe die Frage mal nach unten verschoben, wo neue Sachen auf Diskussionsseiten hingehören.
--AchimP 21:42, 13. Jan. 2008 (CET)Beantworten

Alternative Übersetzung für „Lots of Irritating Superfluous Parentheses“

[Quelltext bearbeiten]

„Lots of Irritating Superfluous Parentheses“ wird bisher als „eine Menge ärgerlicher, überflüssiger Klammern“ übersetzt. Google spuckt bei der Suche nach „eine Menge ärgerlicher, überflüssiger Klammern“ lediglich diesen Wikipedia-Artikel aus, weshalb ich annehme, dass es sich nicht um eine offizielle Übersetzung handelt. Ich denke, dass in diesem Fall „irritierender“ eine bessere Übersetzung für „Irritating“ wäre, als das bisher verwendete „ärgerlicher“. --Ngr 15:16, 4. Mai 2008 (CEST)Beantworten

Ich bin nicht sicher, ob es für „Lots of Irritating Superfluous Parentheses“ überhaupt so etwas wie eine offizielle Übersetzung gibt. Meinem unmaßgeblichen Sprachempfinden nach trifft allerdings „ärgerlich“ eher die Bedeutung von „irritating“ als „irritierend“. Wenn jemand im Englischen „irritated“ ist, ist er/sie eher schon etwas stärker emotionalisiert oder erregt als einfach nur irritiert oder verblüfft. Ich bin kein englischer Muttersprachler, aber zumindest im „Merriam–Webster Dictionary of Synonyms and Antonyms“ finde ich unter „irritate“ die Beschreibung „to excite a feeling of angry annoyance“. Eventuell kann man einfach beide Übersetzungen im Artikel anführen. — Tobias Bergemann 09:02, 5. Mai 2008 (CEST)Beantworten
Zumindest laut dict.leo.org sind die drei gültigen Übersetzungen „ärgerlich“, „irritierend“ und „lästig“. Ich meine, dass „irritierend“ besser passen würde, weil die Klammern ja durchaus irritierend wirken. Das man sich über sie ärgert kommt ja nur daher, dass sie so irritierend sind. Ich denke beide Übersetzungen anzuführen stört den Lesefluss, aber vielleicht kann man es ja geschickt einfädeln. --Ngr 18:14, 15. Mai 2008 (CEST)Beantworten

Abschnitt Bedeutung

[Quelltext bearbeiten]

Dieser Abschnitt ist komplett unbelegt und inhaltlich zumindest fragwürdig.

1. Absatz:

Historisch war Lisp zusammen mit Prolog eine der Programmiersprachen der künstlichen Intelligenz.

Ich würde argumentieren, dass Lisp und Prolog immer noch die bedeutendsten Programmiersprachen sind, die speziell für die KI-Forschung geeignet sind. Neuerdings werden allerdings zunehmend auch Allzwecksprachen wie Java und Python verwendet. Schön wäre natürlich ein Beleg, am besten mit Zahlen. --Thüringer ☼ 16:00, 21. Nov. 2008 (CET)Beantworten

2. Absatz:

Im Unterschied zu Europa, wo Programmiersprachen wie Assembler, Fortran oder Pascal als klassische Vertreter der Familie der prozeduralen Programmiersprachen gelehrt wurden, war und ist zum Teil bis heute in den USA LISP die erste gelehrte Programmiersprache. Das hatte einen großen Einfluss, da es sich bei den klassischen Vertretern der prozeduralen Sprachfamilien um Vertreter einer statischen Verarbeitungsweise von Daten handelt, während dagegen unter anderem LISP ein strikt dynamisches Konzept vertritt.

Das halte ich für bestenfalls anekdotisch, wenn nicht schlichtweg falsch. Der ursprüngliche Autor hat sich inzwischen aus der Wikipedia verabschiedet, also können wir ihn nicht fragen, ob er sich auf die Lehre in Schulen, in der Berufsausbildung oder an Hochschulen bezog. Meiner Erfahrung nach wählen auch europäische Hochschuldozenten oft interessante, nichtprozedurale Programmiersprachen für das Grundstudium aus. Hinzu kommt, dass strikt dynamisches Konzept etwas schwammig formuliert ist. Man könnte viel Interessantes über die Bedeutung von LISP schreiben, aber davon steht nichts in diesem Abschnitt. --Thüringer ☼ 16:00, 21. Nov. 2008 (CET)Beantworten

Ich möchte mich beiden Bemerkungen Anschließen.

zu Absatz 1: Das passt schon zeitlich nicht. Lisp und die Anfänge von KI bzw. AI liegen in den 1950-ern, Prolog ist laut Wikipedia Anfang der 1970-er entwickelt worden. Das Standardwerk zu Prolog "Programming in Prolog" von Clocksin und Mellish datiert auf 1981. Dazwischen liegt also gut eine halbe bis ganze Programmierergeneration.
zu Absatz 2: Als Informatiker und Software-Entwickler, der Anfang der 80-er selbst im Studium intensiv mit Lisp gearbeitet hat, habe ich in der letzten Zeit begonnen, mich wieder damit zu beschäftigen. Allerdings gibt es kaum aktuelle Literatur. Das erste aktuelle, das ich fand, war "Practical Common Lisp" von Peter Seibel (2005) und später das vor kurzem neu aufgelegte "The Scheme Programming Language" von R. Kent Dybvig (2009). Für die angeblich primäre Lehrsprache in den USA ist das etwas dünn. Es ist zwar bedauerlich, aber Lisp ist wohl auch dort eher ein Nischenbewohner (Programmiersprache für Emacs und The Gimp, offizielle GNU-Skript-Sprache Guile, etc.)

Ich bin also dafür, die beiden Aussagen zu entfernen, wobei ein Hinweis auf die Bedeutung von Lisp für die KI durchaus erhalten bleiben sollte.-- Rolfg 00:56, 18. Nov. 2009 (CET)Beantworten

"Ich würde argumentieren, dass Lisp und Prolog immer noch die bedeutendsten Programmiersprachen sind, die speziell für die KI-Forschung geeignet sind." - Was (auch) in meinen Augen völlig unstrittig ist. An diesem Absatz sollte wirklich mal gearbeitet werden, die "Beschwerden" sind alt genug?! Es würde ja bereits besser aussehen, könnte man wenigstens mal den Satz bezgl. der Bedeutung für die KI-Programmierung ins Präsens versetzen. Sofern man damit noch lange wartet, hat e sich u.U. erledigt, aber gegenwärtig und bis auf Weiteres ist die jetzige Aussage irreführend, bzw. unrichtig. -- Zero Thrust 00:07, 18. Jun. 2010 (CEST)Beantworten

EQ und Gleichheit

[Quelltext bearbeiten]

Die Funktion EQ in "klassischen" Lisp-Dialekten und Common Lisp sowie die Funktion eq? in Scheme testen nicht auf Gleichheit sondern auf Objekt-Identität. Identisch ist - wie im wirklichen Leben - ein Objekt im Allgemeinen nur mit sich selbst. Ein paar Beispiele:

(eq 'hugo 'hugo) => T, da der Lisp-Reader Symbole in einer globalen Symboltabelle anlegt.

(eq '(a b) '(a b)) => NIL, da die beiden Listen zwar gleich aussehen, aber nicht dasselbe Objekt sind.

(setf x '(a b)) => (A B)
(setf y x) => (A B)
(eq x y) => T
,
da der Wert von x und y ein und dieselbe Liste ist.

(eq "hugo" "hugo") => NIL; Zeichenketten, die aus der gleiche Buchstabenfolge bestehen, sind trotzdem nicht eq

Ob Zahlen mit demselben Wert eq sind, ist implementierungsabhängig. Die aufgeführten Beispiele wurden mit CLISP ausgewertet. Üblicherweise sind kleine Ganzzahlen, die den selben Wert haben, eq. Verlassen sollte man sich darauf aber nicht.

(eq 5 5) => T
(eq 3.4 3.4) => NIL
(eq 123456789 123456789) => NIL

Dass eq wirklich von "Equal" abgeleitet ist, bezweifle ich. Die Bücher, die mir vorliegen, sprechen von "equivalence". Unter den vielen Vergleichsfunktionen, die Lisp bereitstellt, gibt es auch eine, die equal heißt. Für diese gilt das bestimmt. --Rolfg 16:01, 24. Dez. 2009 (CET)Beantworten

Kommentare

[Quelltext bearbeiten]

Laut Erklärung zur Syntax wird ein Kommentar mit einem einzelnen Semikolon eingeleitet. Allerdings werden im Beispiel zwei Semikola verwendet. Vielleicht sollte man das erklären oder einen eventuellen Tippfehler korrigieren. Ich selbst habe davon leider keinerlei Ahnung. 2001:638:911:10C:134:109:200:105 15:31, 12. Okt. 2016 (CEST)Beantworten

Syntaktisch leitet ein Semikolon einen Kommentar ein. Bei zwei oder mehr Semikola gehören genau genommen alle außer dem ersten bereits zum Kommentartext selbst, haben also keine syntaktische Relevanz.
Allerdings wird in Lisp oft eine unterschiedliche Anzahl von Strichpunkten als Stilmittel verwendet um z.B. Kommentare unterschiedlicher Gewichtung zu unterscheiden. So schreibt z.B. Peter Seibel in seinem Buch "Practical Common Lisp" ([6]):

Finally, comments should be prefaced with one to four semicolons depending on the scope of the comment as follows:

;;;; Four semicolons are used for a file header comment.

;;; A comment with three semicolons will usually be a paragraph

;;; comment that applies to a large section of code that follows,

(defun foo (x)
  (dotimes (i x)
    ;; Two semicolons indicate this comment applies to the code
    ;; that follows. Note that this comment is indented the same
    ;; as the code that follows.
    (some-function-call)
    (another i)              ; this comment applies to this line only
    (and-another)            ; and this is for this line
    (baz)))
--Rolfg (Diskussion) 23:02, 12. Okt. 2016 (CEST)Beantworten