Lisp

knivil

int (*addn(int n))(int)

Da muss die Signatur aber vorher festgelegt sein.

Selbst in C koennte man Funktionen hoeherer Ordnung halbwegs brauchbar auf structs abbilden.

Ja und nein, da die Signatur der Funktion vorher immer bekannt sein muss. Das Lambda im neuen C++ Standard ist eingeschraenkter, als dass in Scheme, Lisp oder Haskell.

Auch weiss ich nicht, warum der symbolische Name so interessant ist. In Scheme wuerde man das Resultat einfach in einer Variablen speichern und dann benutzen. Es ist ein Beispiel fuer Closures. In Scheme wuerde man es wie folgt ausdruecken:

(define (addn n) (lambda (x) (+ x n))) ;; define closure "constructor"
(define add5 (addn 5)) ;; create closure "object" with internal state 5
(define result1 (add5 4)) ;; use closure, result1 is 9
(define result2 (add5 5)) ;; use closure, result2 is 10

(define add6 (addn 6)) ;; create another closure "object" with internal state 6
(define result3 (add6 4)) ;; use closure, result3 is 10

Bashar

Ishildur, es gibt von Paul Graham "On Lisp" irgendwo im Netz. Blätter das mal durch, da wirst du einiges finden ...

Ishildur schrieb:

Das #' dient dazu, dass ein symbolischer Name für die Funktion zurückgegeben wird. Ohne das #' würde die Funktion evaluiert und in einem Kompilerfehler enden, weil der Parameter x fehlt...

Nein, ohne das #' steht da

(defun addn (n)
  (lambda (x) (+ x n)))

Was jetzt passiert, hängt davon ab, ob es eine Funktion LAMBDA gibt: Wenn ja, werden (x) und (+ x n) evaluiert. Letzteres sollte kein Problem sein, das erste greift auf eine (vom Formalparameter x unabhängige!) Funktion X zu, die es entweder gibt oder nicht.
Zum Glück ist LAMBDA aber ein Makro, das nichts anderes tut, als sich in #'(LAMBDA ...) zu transfomieren

Blue-Tiger

knivil schrieb:

int (*addn(int n))(int)
Da muss die Signatur aber vorher festgelegt sein.

Selbst in C koennte man Funktionen hoeherer Ordnung halbwegs brauchbar auf structs abbilden.

Ja und nein, da die Signatur der Funktion vorher immer bekannt sein muss. Das Lambda im neuen C++ Standard ist eingeschraenkter, als dass in Scheme, Lisp oder Haskell.

Du kannst die Signatur mit void*-Pointern allgemein genug halten

knivil

Blue-Tiger schrieb:

Du kannst die Signatur mit void*-Pointern allgemein genug halten

Ja, auch die Anzahl kann man variable halten. Aber trotzdem kriegt man Closures nicht ohne weiteres hin. Auch sind Funktionszeiger nicht wirklich damit vergleichbar, da ich innerhalb der Funktion *int (addn(int n))(int) keinen Zustand gespeichert werden kann (globale Variablen sind keine Loesung).

Ansonsten kannst du gerne diese Zeile in C nachbauen:

(define (addn n) (lambda (x) (+ x n)))

Ich moechte sie genauso oder aehnlich wie im geposteten Schemecode benutzen. Und dann zaehlen wir mal Codezeilen ... Das Hauptproblem ist, dass Funktionen in C keine first class values sind. Closures kann man durch Objekte simulieren, aber braucht natuerlich auch mehr Codezeile.

Blue-Tiger

Deswegen sagte ich ja, dass man Funktionen auf structs abbilden muesste. die koennten zusaetzlichen Status speichern. Allerdings braeuchte es vermutlich einiges an Code und Gehirnschmalz, bis da ein halbwegs brauchbares Framework entsteht, aber es ist fern von "unmoeglich" (schon allein wegen Greenspun's 10th law ).

knivil

aber es ist fern von "unmoeglich"

Selbstzitat (3te Antwort):

Prinzipiell ist alles auch in C moeglich, aber ungemein aufwendig.

Ishildur schrieb:

Ich schreibe gerade eine kleine Arbeit über Lisp und suche in diesem Zusammenhang möglichst viele kleine Programmkonstrukte, welche in C nicht oder nur mit sehr mühsamer Syntax nachgebildet werden können

Das meiste wird auch mit anderen Sprachen als den Lisp's gehen. Was nur in Lisp geht, ist zB sowas:

; Common Lisp (ungetestet)

(defmacro increase (x)
  `(setq ,x (+ ,x 1)))

Dafür müsste man in Sprachen mit Syntax noch eine Struktur für den Syntax-Baum festlegen. Die gleiche Beobachtung erspart dem metalinguistischen Interpreter aus SICP den Parser.
Alles andere sollte auch mit anderen Sprachen machbar sein.

fricky schrieb:

erzähl doch mal, was der macht.

Das ist das gleiche wie zB in Javascript

function addn (n)
{
    return function (x) { return x + n; };
}

Das seltsame # ist eine Besonderheit von Common Lisp, das ist prinzipiell nicht nötig. Common Lisp ist irgendwie ein wenig wie C++.

knivil

Can Your Programming Language Do This?

Bashar schrieb:

Ishildur, es gibt von Paul Graham "On Lisp" irgendwo im Netz. Blätter das mal durch, da wirst du einiges finden ...)

0x06. Dort wirst du sicher genug für eine kleine Arbeit finden:
http://www.paulgraham.com/onlisp.html

Zu Continuations willst du vielleicht auch das Kapitel über Web Applications in PLAI lesen:
http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/

Wie man sowas in CL nachbaut, steht wiederum bei Graham.

knivil schrieb:

Aber trotzdem kriegt man Closures nicht ohne weiteres hin.

Sollte schon recht einfach gehen. Closures kann man als Verschachtelung von assioziativen Arrays beschreiben (oder durch name mangling, wenn du's hart übersetzen willst). Continuations bekommst du dann als Verschachtelung von Closures.

knivil

Closures kann man als Verschachtelung von assioziativen Arrays beschreiben

Ich verstehe nicht so recht, was deine Idee ist. Aber vom Array ist es nun gar nicht weit zur List und wir waeren bei Lisp. Und was das bedeutet, hat Blue-Tiger ja schon gesagt: Greenspun's 10th law. Klar geht alles, aber muss man dafuer unbedingt Lisp nachbauen? Anscheinend schon.

knivil schrieb:

Klar geht alles, aber muss man dafuer unbedingt Lisp nachbauen? Anscheinend schon.

in C geht alles, in Lisp auch? man kann in C Lisp nachbauen, kann man auch mit Lisp C nachbauen? wahrscheinlich ja.

knivil

Der grosse Unterschied ist, dass man C nicht mit Lisp nachbauen will.

knivil schrieb:

Der grosse Unterschied ist, dass man C nicht mit Lisp nachbauen will.

echt? wäre das wirklich so schwierig? hätt' ich ja nicht gedacht.

Lisp ist doch unleserlich ohne Ende. Dagegen ist jeder Quellcode aus einem C-Obfuscation-contest noch kinderleicht zu lesen.

knivil schrieb:

Ich verstehe nicht so recht, was deine Idee ist.

Stell dir vor, du willst einen Interpreter für eine Sprache mit Closures schreiben, und zwar verwendest du dafür eine Sprache, die keine Closures kennt, zB C. Du wirst dabei für jede Funktion, die auch Closure ist, eine Menge von Namen haben, die ausserhalb der Funktion festgelegt wurden, und denen also für jede Closure (jedes? jeden?) jeweils irgendein spezieller Wert zugeordnet werden muss. Dafür bieten sich assoziative Arrays an. Und weil Closures prinzipiell etwas verschachtelbares sind, müssen es auch die assoziativen Arrays sein.

knivil schrieb:

Aber vom Array ist es nun gar nicht weit zur List und wir waeren bei Lisp.

"Assoziatives Array" ist vielleicht unglücklich, aber das sagt man eben so. Ich meine sowas wie eine Hashtabelle oder einen Suchbaum von Zuordnungen. Ich hätte besser einfach gesagt: "Tabelle". Bau sowas mal in Lisp nach, wenn der Interpreter keine Hashfunktion ala "gib mir den Zeiger als Zahl" kennt.

;fricky schrieb:

in C geht alles, in Lisp auch? man kann in C Lisp nachbauen, kann man auch mit Lisp C nachbauen? wahrscheinlich ja.

Warum auch nicht?

Zeus

Habt ihr nix sinnvolles zu tun?

Zeus schrieb:

Habt ihr nix sinnvolles zu tun?

Nö, wir sind nämlich so reich, dass wir uns nur noch fragen, ob's Spass macht.

ddddddddddddds schrieb:

Lisp ist doch unleserlich ohne Ende.

ich hab zwar 0 ahnung von lisp, aber ich glaube, dass diese sprache ganz schön mächtig ist. diese vielen klammern sehen ziemlich fürchterlich aus, aber ein lisp-kenner wird sie wahrscheinlich garnicht mehr wahrnehmen.

so selten, wie Lisp in der Praxis eingesetzt wird, muß das wirklich eine ganz schön mächtige Sprache sein

man kann mit Lisp C nachbauen und mit C Lisp nachbauen, ist schließlich beides Turing-vollständig. Man kann aber Lisp mit nur einer halben Seite Lisp nachbauen, geht das in C auch ?

wie hieß doch gleich "Greenspuns Tenth Rule of Programming" ?