Die erste Vorlesung diente zur Organisation des Semesters und zur Einführung in die Sprache Common LISP. Wir haben diskutiert, was LISP von anderen Sprachen unterscheidet (mehr dazu siehe unten sowie in den slides zur Vorlesung auf dem Ilias server).
Des Weiteren haben wir uns die Syntax angeschaut, d.h. “S-Expressions” (symbolic expressions) und Prefix (oder “Polish”) Notation, sowie das Konzept der Evaluierung von Formen: “A lisp form is a lisp datum that is also a program, that is, it can be evaluated without an error.”
Wir haben uns mit der Evaluierungsreihenfolge beschäftigt. Lisp evaluiert Formen rekursiv. Hierzu ein kleines Beispiel aus diesem online LISP Tutorial. Folgende form soll evaluiert werden:
(+ 33 (* 2.3 4)) 9)
- The + function is looked up.
- 33 is evaluated (its value is 33).
- (* 2.3 4) is evaluated:
- The * function is looked up.
- 2.3 is evaluated (its value is 2.3)
- 4 is evaluated (its value is 4)
- 2.3 and 4 are passed to the * function.
- The * function returns 9.2. This is the value of (* 2.3 4).
- 9 is evaluated (its value is 9).
- 33, 9.2, and 9 are passed to the + function.
- The + function returns 51.2. This is the value of (+ 33 (* 2.3 4) 9).
- The Lisp system returns 51.2.
Wir haben sodann verschiedene Datentypen kennengelernt: symbols, floats, integers und ratios.
Wir haben unsere ersten Programmierversuche gestartet und unsere ersten kleinen LISP forms geschrieben. Dabei haben wir sog. “primitive functions” (Funktionen, die bereits in der Sprache implementiert sind) verwendet, um Operationen mit Daten auszuführen. Diese waren: (*für die u.s. Tabellen nehmen wir an, die Variable A hätte den Wert 10 und Variable B den Wert 20) :
Arithmetische Operatoren
+, -, *, /, mod, rem, incf, decf
| Operator | Description | Example |
|---|---|---|
| + | Adds two operands | (+AB) will give 30 |
| - | Subtracts second operand from the first | (- A B) will give -10 |
| * | Multiplies both operands | (* A B) will give 200 |
| / | Divides numerator by de-numerator | (/ B A) will give 2 |
| mod,rem | Modulus Operator and remainder of after an integer division | (mod B A )will give 0 |
| incf | Increments operator increases integer value by the second argument specified | (incf A 3) will give 13 |
| decf | Decrements operator decreases integer value by the second argument specified | (decf A 4) will |
Prädikatsfunktionen
equalp, symbolp, numberp, oddp, evenp
| Operator | Description | Example |
|---|---|---|
| equalp | Checks if the values of the two arguments are equal | (= A B) is not true. |
| symbolp | Checks if the value of the argument is a symbol | (symbolp A) is not true |
| numberp | Checks if the value of the argument is a number | (numberp A) is true. |
| oddp | Checks if the value of the argument (integer) is odd | (oddp A) is not true |
| evenp | Checks if the value of the argument (integer) is even | (evenp A) is true |
Vergleichsoperatoren
=, /=, >, <, >=, <=, max, min
| Operator | Description | Example |
|---|---|---|
| = | Checks if the values of the operands are all equal or not, if yes then condition becomes true. | (= A B) is not true. |
| /= | Checks if the values of the operands are all different or not, if values are not equal then condition becomes true. | (/= A B) is true. |
| > | Checks if the values of the operands are monotonically decreasing. | (> A B) is not true. |
| < | Checks if the values of the operands are monotonically increasing. | (< A B) is true. |
| >= | Checks if the value of any left operand is greater than or equal to the value of next right operand, if yes then condition becomes true. | (>= A B) is not true. |
| <= | Checks if the value of any left operand is less than or equal to the value of its right operand, if yes then condition becomes true. | (<= A B) is true. |
| max | It compares two or more arguments and returns the maximum value. | (max A B) returns 20 |
| min | It compares two or more arguments and returns the minimum value. | (min A B) returns 20 |
Logische Operatoren
Hierfür nehmen wir an, A hat den Wert NIL (false) und B hat den Wert 5 (true).
| Operator | Description | Example |
|---|---|---|
| and | It takes any number of arguments. The arguments are evaluated left to right. If all arguments evaluate to non-nil, then the value of the last argument is returned. Otherwise nil is returned. | (and A B) will return NIL. |
| or | It takes any number of arguments. The arguments are evaluated left to right until one evaluates to non-nil, in such case the argument value is returned, otherwise it returns nil. | (or A B) will return 5. |
| not | It takes one argument and returns t if the argument evaluates to nil. | (not A) will return T. |
Danach haben wir die Macro Funktion “defun” kennen gelernt, um unsere eigenen Funktionen zu definieren. Dies haben wir dann mit der Programmierung eines kleinen Würfelspiels zur Anwendung gebracht.
Hier noch ein etwas anekdotischer, nichtsdestotrotz interessanter Text aus P. Graham’s Buch “On Lisp” (1.5):
Why LISP? (or When)
These new possibilities do not stem from a single magic ingredient. In this respect, Lisp is like an arch. Which of the wedge-shaped stones (voussoirs) is the one that holds up the arch? The question itself is mistaken; they all do. Like an arch, Lisp is a collection of interlocking features. We can list some of these features— dynamic storage allocation and garbage collection, runtime typing, functions as objects, a built-in parser which generates lists, a compiler which accepts programs expressed as lists, an interactive environment, and so on—but the power of Lisp cannot be traced to any single one of them. It is the combination which makes Lisp programming what it is.
Over the past twenty years, the way people program has changed. Many of these changes—interactive environments, dynamic linking, even object-oriented programming—have been piecemeal attempts to give other languages some of the flexibility of Lisp. The metaphor of the arch suggests how well they have succeeded.
It is widely known that Lisp and Fortran are the two oldest languages still in use. What is perhaps more significant is that they represent opposite poles in the philosophy of language design. Fortran was invented as a step up from assembly language. Lisp was invented as a language for expressing algorithms. Such different intentions yielded vastly different languages. Fortran makes life easy for the compiler writer; Lisp makes life easy for the programmer. Most programming languages since have fallen somewhere between the two poles. Fortran and Lisp have themselves moved closer to the center. Fortran now looks more like Algol, and Lisp has given up some of the wasteful habits of its youth.
The original Fortran and Lisp defined a sort of battlefield. On one side the battle cry is “Efficiency! (And besides, it would be too hard to implement.)” On the other side, the battle cry is “Abstraction! (And anyway, this isn’t production software.)” As the gods determined from afar the outcomes of battles among the ancient Greeks, the outcome of this battle is being determined by hardware. Every year, things look better for Lisp. The arguments against Lisp are now starting to sound very much like the arguments that assembly language programmers gave against high-level languages in the early 1970s. The question is now becoming not Why Lisp?, but When?
Auch sehr empfehlenswert ist das Vorwort von P. Norvig zu seinem Buch “Paradigms of artificial intelligence programming: case studies in Common LISP“.
Hier noch ein link zu einem historischen Überblick von LISP Implementierungen: http://www.softwarepreservation.org/projects/LISP/